Los ciberataques con IA ya no dejan semanas para parchear vulnerabilidades: dejan horas. McKinsey publicó un análisis de la seguridad del software en la era de los modelos de frontera, los sistemas de inteligencia artificial más avanzados, y la brecha es brutal en los dos sentidos. El atacante tarda horas en explotar un fallo crítico recién divulgado. La empresa tarda 43 días en corregirlo por completo.
Ese contraste ordena el informe. Durante décadas, la defensa descansó en dos ideas: explotar un fallo pedía una pericia rara, y quien defendía tenía tiempo para arreglar con calma. McKinsey plantea que las dos murieron. Un modelo de frontera lee código con mentalidad de atacante, produce ataques funcionales y despliega agentes que buscan fallos en cadena, capacidad que ya aparece en modelos de pesos abiertos.
Las cifras lo confirman. Anthropic lanzó en abril de 2026 Project Glasswing y en mayo informó que sus socios habían encontrado más de 10.000 vulnerabilidades graves con Claude Mythos Preview; varios multiplicaron por más de diez su ritmo de hallazgos. Entre lo destapado hay un fallo de Firefox con 20 años y otro de OpenBSD con 27. Ese modelo ya obligó a la banca a mover equipos enteros para corregir fallos, como contó el caso de Claude Mythos y las vulnerabilidades en los bancos.
El ecosistema público muestra la misma presión. Los fallos corregidos por versión del núcleo de Linux pasaron de unos 500 entre las versiones 6.9 y 6.19 a más de 1.000 desde la 7.0, con datos de un mantenedor del núcleo. HackerOne reportó en abril un alza del 76 % interanual en los envíos a su plataforma, con la proporción de válidos estable: no es ruido, es volumen real.
Ciberataques con IA en horas, defensas de 43 días
Del lado de la explotación, el reloj corre rápido. McKinsey recoge que el tiempo medio entre la divulgación de una vulnerabilidad crítica y su explotación activa bajó a cuestión de horas, cuando hace un año se medía en semanas. En 2026, dos tercios de las explotadas recibieron ataques el mismo día de su divulgación o antes. Del lado de la defensa, el movimiento es inverso: el análisis del informe Data Breach Investigations Report 2026 de Verizon sobre las vulnerabilidades explotadas de CISA sitúa la mediana de corrección en 43 días, frente a 32 del ciclo anterior, con solo un 26 % corregido del todo.
La escena de esa brecha tiene día y hora: un aviso de fin de semana en un producto de acceso remoto muy instalado, con la guía del fabricante incompleta. La empresa recibe más alertas de las que nadie lee y la jugada útil en esas horas suele ser apagar el servicio expuesto. En octubre quedaron dos ejemplos: PHP2Shell, dos vulnerabilidades críticas de PHP, y Node2Shell, un fallo grave en Node.js, ambos con ejecución remota de código e intentos de explotación observados en el caso de PHP.
El dinero juega en contra del defensor. Pedirle a un modelo que busque fallos sale barato; escanear a fondo una organización cuesta mucho más, y corregir, más todavía. Empresas que ya usan estas herramientas contaron a McKinsey que el primer escaneo de sus sistemas más valiosos terminó en días o semanas, mientras la corrección se estira durante meses. Cada equipo apartado para tapar fallos deja de construir el producto que sostiene el negocio.
Parchear vulnerabilidades con un plan de 90 días
Los reguladores ya entraron con fechas concretas. En abril de 2026, el secretario del Tesoro de Estados Unidos, Scott Bessent, y el entonces presidente de la Reserva Federal, Jerome Powell, reunieron a directivos de grandes bancos por las implicaciones del modelo Mythos. El 7 de julio, la supervisión bancaria del Banco Central Europeo pidió a las entidades significativas planes de acción con entrega el 31 de octubre: acelerar los parches, montar defensas con IA y proteger proveedores y activos expuestos. El Banco de Inglaterra y CERT-EU publicaron guías similares.
La propuesta de McKinsey mueve cuatro palancas a la vez: prácticas, modelo operativo, marco de riesgo y tecnología. En la práctica diaria eso se traduce en decisiones concretas. Usar varios modelos a la vez, porque cada uno encuentra fallos distintos y confiar en una sola herramienta deja puntos ciegos. Juntar los hallazgos en un registro único, con dueño. Exigir una prueba reproducible antes de ocupar a un desarrollador. Fijar tolerancias por activo: días para un sistema expuesto a internet, un trimestre para una herramienta interna sin camino a datos críticos. Y calificar el riesgo por explotabilidad e impacto, no por la etiqueta de gravedad: ordenar corregir todo lo crítico en pocos días deja de cumplirse cuando el volumen se multiplica por diez.
El arranque dura 90 días y empieza pequeño: pocos sistemas críticos y una ruta de entrega. El primer mes define alcance y responsables, corre el primer escaneo multimodelo y confirma lo básico: autenticación multifactor, privilegios mínimos y restauración probada. El segundo mes pone el piloto a trabajar con acceso acotado para los agentes. El tercer mes mide tres números: contención, corrección verificada y exposición abierta.
Para quien dependa de un proveedor, queda un dato para copiar hoy a la agenda: McKinsey recomienda seguir la velocidad de parcheo de cada proveedor crítico como indicador de riesgo y acordar de antemano aislar o apagar un servicio si incumple su plazo. Con ataques en horas, esperar al correo del fabricante dejó de ser un plan.
Fuente: McKinsey
