El día que murieron 8,5 millones de ordenadores: lo que la caída de CrowdStrike me enseñó sobre construir software que no puede fallar
Estaba sentado en el vestíbulo de un hotel en Hyderabad cuando mi teléfono empezó a vibrar. No era el goteo habitual de notificaciones de Slack: era una avalancha. Toda la flota de máquinas Windows de un cliente se había puesto azul. Luego otro cliente. Luego saltó la noticia: aeropuertos que dejaban en tierra los vuelos, hospitales que cancelaban cirugías, bancos que congelaban transacciones. Todo por una única actualización de archivo de CrowdStrike más pequeña que la foto que le sacarías a tu almuerzo.
19 de julio de 2024. El día en que aproximadamente 8,5 millones de sistemas Windows se estrellaron simultáneamente contra la Pantalla Azul de la Muerte. El día que acabaría costándole a la economía global más de 10.000 millones de dólares en daños. Y el día en que me obsesioné con una pregunta que aún me quita el sueño: ¿Por qué estamos construyendo los sistemas más críticos de la historia de la humanidad sobre cimientos que pueden ser destruidos por un archivo de configuración?
Dirijo Veriprajna, una consultora de IA. Construimos lo que yo llamo soluciones de «IA Profunda»: sistemas que se integran con la infraestructura central, no las finas envolturas de ChatGPT que dominan el mercado en este momento. Cuando ocurrió la caída de CrowdStrike, la mitad de la industria de la IA se encogió de hombros. «Es un problema de seguridad», dijeron. «No es nuestro dominio». Pero yo vi algo diferente. Vi exactamente la misma fragilidad arquitectónica que aqueja a toda empresa que se apresura a atornillar IA a sus operaciones sin entender lo que ocurre por debajo.
Pasé meses después de la caída desmenuzando el análisis de causa raíz, siguiendo el litigio de Delta Air Lines y estudiando la investigación emergente sobre verificación formal. Lo que encontré cambió cómo mi equipo lo construye todo. Escribí un desglose interactivo y exhaustivo del análisis completo aquí, pero este ensayo es la historia detrás de la investigación: las partes que no encajan limpiamente en un whitepaper.
Un archivo más pequeño que un JPEG derribó la aviación global
Esto es lo que realmente ocurrió, despojado de la jerga.
La plataforma de seguridad Falcon de CrowdStrike se ejecuta dentro del kernel de Windows: la capa más profunda y privilegiada del sistema operativo. Piénsalo como la sala de máquinas de un barco. Si algo sale mal arriba en cubierta, puedes arreglarlo. Si algo sale mal en la sala de máquinas, el barco se hunde.
Para detectar nuevas amenazas rápidamente, CrowdStrike construyó un sistema llamado «Rapid Response Content» (Contenido de Respuesta Rápida). En lugar de enviar actualizaciones de software completas (que son lentas y requieren pruebas), envían pequeños archivos de configuración: básicamente hojas de instrucciones que le dicen al motor de seguridad qué patrones buscar. Es ingenioso. También es, como aprendimos, aterradoramente peligroso.
Aquella mañana, se desplegaron dos nuevos conjuntos de instrucciones para detectar un tipo específico de comunicación entre procesos. Estas instrucciones hacían referencia a 21 parámetros de entrada. ¿El problema? El motor que se ejecutaba en cada endpoint —el código real que se ejecuta en el kernel— solo entendía 20 parámetros.
La nube decía «lee 21 campos». El kernel solo conocía 20. Ese desajuste estrelló 8,5 millones de ordenadores.
El validador en la nube aprobó la actualización porque su definición de la plantilla incluía 21 campos. Estaba comprobando contra su propia expectativa, no contra la realidad de lo que el endpoint podía manejar. Cuando el intérprete a nivel de kernel intentó acceder a ese vigésimo primer campo, leyó más allá del límite de la memoria asignada. En el espacio del kernel, eso no es un error recuperable. Es un fallo instantáneo. Pantalla azul. Reinicio. Fallo de nuevo. Reinicio. Fallo de nuevo. Un bucle de muerte infinito.
Recuerdo explicarle esto a un inversor no técnico durante una cena unas semanas después. Me miró fijamente y dijo: «¿Entonces me estás diciendo que nadie probó si la cosa que recibía la actualización podía realmente procesar la actualización?». Asentí. Soltó el tenedor. «Eso no es un error de software. Eso es negligencia».
No se equivocaba. Y un juez de Georgia esencialmente estaría de acuerdo con él.
Por qué 40.000 servidores tuvieron que ser arreglados a mano
La parte de la historia que no recibe suficiente atención es la recuperación, o más bien, la imposibilidad de la recuperación remota.
Aquí está la cruel ironía: el agente de CrowdStrike es lo que recibe comandos desde la nube. «Revierte esta actualización». «Aplica esta corrección». Pero el fallo ocurrió tan temprano en la secuencia de arranque que el agente nunca se inicializó. El software que se suponía que debía recibir la señal de rescate era precisamente lo que causaba el ahogamiento.
Mi equipo empezó a llamar a esto el problema del «Agente Muerto». Cada máquina afectada quedaba huérfana. No podía comunicarse con el servidor central. No podía recibir instrucciones. La única solución era arrancar físicamente cada máquina en Modo Seguro, navegar hasta C:\Windows\System32\drivers\CrowdStrike\ y eliminar manualmente el archivo defectuoso.
Para Delta Air Lines, eso significó tocar aproximadamente 40.000 servidores y miles de estaciones de trabajo. A mano. Una a una.
He gestionado operaciones de recuperación de TI antes, y la logística de esa escala es casi incomprensible. Necesitas acceso físico a máquinas que podrían estar en salas de servidores cerradas con llave en distintas ciudades. Necesitas técnicos que sepan arrancar en Modo Seguro, lo cual, en una era de cifrado BitLocker, a menudo requiere claves de recuperación que están almacenadas en... otros servidores que también están caídos. Son tortugas hasta el fondo.
Los competidores de Delta —American Airlines, United— se recuperaron en uno a tres días. La interrupción de Delta duró más de cinco días y resultó en más de 7.000 vuelos cancelados y 550 millones de dólares en pérdidas. ¿La diferencia? El sistema de seguimiento de tripulaciones de Delta, el software que le dice a la aerolínea dónde están sus pilotos y auxiliares de vuelo y cuándo están disponibles, se ejecutaba casi por completo sobre Windows. Cuando esos servidores murieron, Delta no solo perdió ordenadores. Perdió la capacidad de saber dónde estaba su propia gente.
¿Qué ocurre cuando un error de software se convierte en «negligencia grave»?
Aquí es donde la historia se traslada de la sala de servidores a la sala del tribunal, y donde creo que las implicaciones se vuelven verdaderamente transformadoras para la industria.
Delta demandó a CrowdStrike. Eso por sí solo no es sorprendente: las empresas demandan a los proveedores tras fallos importantes todo el tiempo. Lo sorprendente es lo que el juez permitió que prosperara.
Históricamente, los proveedores de software han estado protegidos por sus contratos. Enterrado en los términos de servicio siempre hay un tope de responsabilidad, normalmente limitado a lo que el cliente pagó por la suscripción. Es un arreglo cómodo. Vendes software que opera en el nivel más profundo de la infraestructura de un cliente, y si lo destruye todo, tu exposición máxima son doce meses de tarifas de licencia.
En mayo de 2025, la jueza Kelly Lee Ellerbe del Tribunal Superior del condado de Fulton se negó a desestimar las reclamaciones de Delta por negligencia grave y —esta es la que me hizo enderezarme en la silla— allanamiento informático.
El argumento de la negligencia grave es sencillo: CrowdStrike envió la actualización a los 8,5 millones de sistemas simultáneamente. Sin despliegue escalonado. Sin implementación canaria. Sin «probemos esto primero en el 1 % de las máquinas y veamos qué pasa». Los abogados de Delta argumentaron que esto representaba un desprecio consciente por riesgos conocidos. El propio informe posterior al incidente de CrowdStrike admitió que el Validador de Contenido tenía un error de lógica y que el Intérprete de Contenido carecía de una comprobación de límites en tiempo de ejecución.
Pero la reclamación por allanamiento informático es la que debería aterrar a todo proveedor de SaaS que lea esto. Delta había optado por no recibir actualizaciones automáticas en su configuración. CrowdStrike envió la actualización de todos modos a través del mecanismo de archivo de canal a nivel de kernel. La jueza dictaminó que los deberes legales relativos al allanamiento informático son independientes del acuerdo de suscripción, lo que significa que el tope de responsabilidad del contrato no se aplica.
Cuando un proveedor anula tus preferencias explícitas para introducir código en tu kernel, el tope de responsabilidad del contrato podría no protegerlo. Esa es la nueva realidad legal.
He hablado con tres CISO diferentes desde este fallo, y cada uno de ellos dijo lo mismo: «Estamos reescribiendo nuestros acuerdos con proveedores». La era de la confianza ilimitada en las actualizaciones automáticas de los proveedores de seguridad ha terminado.
El incómodo paralelismo con la industria de la IA
Ahora aquí es donde voy a ser franco, y donde a algunos de mis colegas del ámbito de la IA no les va a gustar lo que tengo que decir.
La industria de la IA está construyendo sobre los mismos cimientos frágiles que CrowdStrike expuso. Solo que lo estamos haciendo más rápido y con más bombo.
El mercado en este momento está dominado por lo que yo llamo «envolturas de LLM»: finas capas de aplicación que hacen llamadas a la API de GPT-4 o Claude, envuelven la respuesta en una interfaz bonita y lo llaman un producto de IA. He visto presentaciones de empresas cuya arquitectura técnica entera es literalmente «enviamos un prompt a OpenAI y mostramos el resultado». Están valoradas en decenas de millones de dólares.
El año pasado estuve en una conferencia donde un fundador demostraba con orgullo su «herramienta de análisis de seguridad impulsada por IA». Le hice una pregunta sencilla: «¿Qué pasa si OpenAI cambia su API, sube los precios 10 veces o se cae durante seis horas?». Me miró como si le hubiera preguntado qué pasa si la gravedad deja de funcionar. «Eso no va a pasar», dijo.
Va a pasar. Siempre pasa. La caída de CrowdStrike demostró que incluso los proveedores de infraestructura más confiables, aquellos sobre los que has apostado toda tu operación, pueden enviar un único archivo defectuoso y derribarlo todo.
Por eso construimos Veriprajna en torno a lo que yo llamo «IA Profunda», y quiero ser preciso sobre lo que quiero decir, porque el término se usa a la ligera.
Una solución de IA Profunda no alquila su inteligencia a un único proveedor externo. Utiliza arquitecturas híbridas —modelos de lenguaje pequeños especializados, modelos de visión-lenguaje, redes neuronales de grafos— desplegados sobre la propia infraestructura del cliente cuando el caso de uso lo exige. Se integra a nivel de sistema, no a nivel de interfaz. Y, de forma crítica, utiliza verificación formal para proporcionar garantías matemáticas sobre su comportamiento, no solo las mejores conjeturas probabilísticas.
La diferencia importa. Una envoltura de LLM te da un chatbot que suele acertar. Un sistema de IA Profunda te da un motor que es demostrablemente correcto para la tarea específica para la que fue diseñado.
Por qué me obsesioné con la verificación formal
Seré honesto: antes de la caída de CrowdStrike, pensaba que la verificación formal era una curiosidad académica. Algo sobre lo que los investigadores publicaban artículos y que nadie usaba en producción. El microkernel seL4 —un kernel de sistema operativo verificado formalmente— era impresionante, pero parecía un logro aislado que requería años de esfuerzo a nivel de doctorado.
Entonces leí el análisis de causa raíz de CrowdStrike por tercera vez, y algo encajó.
Todo el desastre se reducía a una brecha semántica. El validador en la nube creía que la plantilla tenía 21 campos. El intérprete del endpoint creía que tenía 20. Dos componentes del mismo sistema sostenían creencias contradictorias sobre la realidad, y nadie lo detectó porque no había una especificación compartida y matemáticamente rigurosa contra la cual ambos componentes fueran verificados.
La verificación formal elimina las brechas semánticas. Utiliza pruebas matemáticas para garantizar que el software —la implementación real— siempre satisface su especificación. No «normalmente». No «en nuestras pruebas». Siempre. Si la prueba se sostiene, el software no puede violar su especificación. Punto.
El año pasado mi equipo pasó semanas experimentando con un marco llamado VeCoGen, que combina modelos de lenguaje grandes con motores de verificación formal para generar automáticamente código C verificado. El LLM propone implementaciones candidatas, y un verificador de pruebas confirma matemáticamente la corrección antes de que se despliegue nada. Si el código tiene un error —incluso uno sutil como un error de índice por uno en el límite de un arreglo— la prueba falla y el código se rechaza.
Recuerdo la primera vez que lo pusimos a funcionar en un ejemplo no trivial. Mi ingeniero principal, que había sido escéptico con todo el empeño, miró la salida verificada y dijo: «¿Entonces la IA escribe el código y la prueba de que el código es correcto?». Sí. Y el verificador de pruebas es un sistema separado y de confianza al que no le importa la confianza de la IA: solo le importa la verdad matemática.
Estamos entrando en una era en la que el código generado por IA se preferirá sobre el código artesanal, no porque la IA sea más lista, sino porque la IA puede generar la prueba matemática junto con la implementación.
Martin Kleppmann hizo esta predicción recientemente, y creo que tiene toda la razón. El «verificador de pruebas» se convierte en el guardián. Sin prueba, no hay despliegue. Es lo opuesto al modelo de CrowdStrike, donde el validador esencialmente daba el visto bueno a las actualizaciones basándose en sus propias suposiciones.
¿Y si el sistema se hubiera podido curar a sí mismo?
Hay un detalle sobre el 19 de julio que me persigue. El fallo ocurrió globalmente, en los 8,5 millones de endpoints, porque no había ningún mecanismo automatizado para detectar el patrón de fallo y detener el despliegue en tiempo real.
Piénsalo. Millones de máquinas empezaron a fallar simultáneamente. Las señales de telemetría estaban ahí: lecturas de memoria fuera de límites, pánicos inmediatos del kernel, bucles de arranque. Pero ningún sistema vigilaba esas señales de una manera que pudiera activar un interruptor de apagado automático.
Este es el problema que la telemetría impulsada por IA está diseñada para resolver. La monitorización tradicional funciona con reglas estáticas: «Alerta si el uso de CPU supera el 90 %». Es como poner un detector de humo que solo se dispara cuando la casa ya está en llamas. Lo que necesitas es un sistema que entienda cómo se ve lo «normal» a un nivel granular y que pueda detectar los primeros microsegundos de desviación.
Hemos estado construyendo lo que la comunidad investigadora llama Análisis de Telemetría Impulsado por IA, o marcos AITA. Estos usan aprendizaje automático no supervisado —bosques de aislamiento, autocodificadores, agrupamiento basado en densidad— para establecer líneas base de comportamiento de los componentes del sistema. Los resultados de investigaciones recientes son sorprendentes: reducción del 35 % en el tiempo medio para detectar anomalías, reducción del 40 % en falsos positivos, y precisión de detección de anomalías que alcanza un 97,5 % de precisión con un 96,2 % de exhaustividad.
En el escenario de CrowdStrike, un sistema habilitado con AITA habría detectado la lectura fuera de límites como una desviación del comportamiento de referencia dentro de los primeros milisegundos de aplicarse la actualización. Podría haber activado un interruptor de apagado local —aislando el controlador defectuoso, revirtiendo a la última configuración estable conocida— antes de que el fallo se propagara en cascada. No después de que 8,5 millones de máquinas cayeran. Antes de que la segunda máquina cayera.
No estamos hablando de ciencia ficción. Estamos hablando de sistemas que ya existen en la investigación y que están pasando a producción. La pregunta no es si las empresas adoptarán arquitecturas autorreparables. Es si las adoptarán antes o después de la próxima cascada global.
¿Cómo se construye realmente para este futuro?
La gente siempre me pregunta alguna versión de: «Vale, estoy convencido de que esto importa. Pero mi empresa no puede reconstruirlo todo desde cero. ¿Por dónde empezamos?».
Pregunta justa. Aquí es donde ha aterrizado mi pensamiento tras un año trabajando en esto.
Primero, audita lo que se está ejecutando en tu kernel. La mayoría de las empresas no tienen ni idea de cuántos agentes de terceros están operando en el Anillo 0, el nivel de privilegio más profundo. Cada uno de esos agentes es un riesgo potencial al estilo CrowdStrike. Exige que cualquier proveedor que opere a nivel de kernel proporcione evidencia de procedimientos de despliegue escalonado, versionado de esquemas entre sus validadores en la nube y los intérpretes de los endpoints, y pruebas de simulación de bucles de arranque. Si no pueden proporcionarla, esa es tu respuesta sobre su rigor de ingeniería.
Segundo, deja de tratar la IA como una capa de interfaz. Si tu «estrategia de IA» es una colección de herramientas envoltura de LLM que dependen todas de los mismos dos o tres proveedores de modelos, tienes un riesgo de concentración que refleja el problema de dependencia de CrowdStrike. Empieza a construir o adquirir modelos especializados que se ejecuten en tu infraestructura para tus flujos de trabajo más críticos. Esto es lo que significa la soberanía de la IA en la práctica: no ideología, sino resiliencia operativa.
Tercero, convierte la verificación formal en un requisito de adquisición, no en una aspiración de investigación. Las herramientas existen ahora. VeCoGen y marcos similares están haciendo posible generar código verificado a escala. Para cualquier componente crítico para la seguridad —cualquier cosa que toque el kernel, procese transacciones financieras o tome decisiones médicas— exige una prueba matemática de corrección, no solo porcentajes de cobertura de pruebas.
Tuve una discusión con un cliente potencial sobre este último punto. Dijo: «Nos estás pidiendo que ralenticemos nuestra canalización de despliegue». Le dije: «La canalización de despliegue de CrowdStrike era muy rápida. Envió una actualización defectuosa a 8,5 millones de máquinas en minutos. La velocidad no era el problema. La velocidad sin verificación era el problema».
Firmó el contrato.
El precedente que lo cambia todo
Esto es lo que creo que la mayoría de la gente en tecnología se está perdiendo sobre el caso Delta contra CrowdStrike.
El fallo por negligencia grave no trata solo de una aerolínea y un proveedor de seguridad. Está estableciendo un nuevo estándar de diligencia para las actualizaciones automáticas de software. Cuando un juez dice que enviar código sin probar a millones de máquinas sin despliegue escalonado podría constituir negligencia grave, eso se aplica a todo proveedor que haga lo mismo. Cuando un juez dice que anular las preferencias de actualización de un cliente para introducir código a nivel de kernel podría constituir allanamiento informático independientemente del contrato, eso reescribe las reglas para toda empresa de SaaS con mecanismos de actualización automática.
La «negligencia grave» de hoy se convertirá en la expectativa de referencia del mañana. Despliegues escalonados, verificación formal, comprobación de límites en tiempo de ejecución, telemetría autorreparable: estos ya no son ventajas competitivas. Son el estándar mínimo que los tribunales y los reguladores exigirán.
Y aquí está lo que me entusiasma, incluso cuando me aterra: la industria de la IA está a punto de enfrentarse a este mismo ajuste de cuentas. Ahora mismo, la mayoría de los sistemas de IA operan de forma probabilística: «suelen acertar», y cuando se equivocan, nos encogemos de hombros y lo llamamos una alucinación. Pero a medida que la IA se adentra más en la infraestructura crítica —gestionando redes eléctricas, aprobando tratamientos médicos, ejecutando transacciones financieras— «suele acertar» tendrá el mismo peso legal que «no probamos la actualización antes de enviarla a 8,5 millones de máquinas».
El coste de 10.000 millones de dólares de la caída de CrowdStrike no es el precio de un error. Es el pago inicial de una actualización global de cómo construimos y verificamos el software.
Las empresas que entiendan esto —que inviertan ahora en IA Profunda, verificación formal y arquitecturas soberanas— no solo evitarán la próxima catástrofe. Definirán el estándar que todos los demás se apresurarán a cumplir después de que ocurra.
Sé de qué lado de esa división quiero estar. La pregunta es si tú elegirás antes del próximo 19 de julio, o después.
