El problema de la velocidad: Cómo la IA de frontera expone las debilidades de la ciberseguridad de las empresas

| Artículo

Nota: Hacemos nuestro mejor esfuerzo por preservar el espíritu original y los matices de nuestros artículos. Sin embargo, nos disculpamos de antemano por cualquier falla de traducción que pueda notar. Agradecemos sus comentarios en reader_input@mckinsey.com

Se ha producido un an important shift in enterprise cybersecurity, and it is not the arrival of more sophisticated malware. It is the collapse of time.cambio importante en la ciberseguridad de las empresas, y no se trata de la llegada de malware más sofisticado. Se trata del desplome de los tiempos.

Durante décadas, las organizaciones gestionaron el riesgo cibernético bajo el supuesto de que disponían de tiempo para detectar vulnerabilidades, evaluar su gravedad, pasar por los procesos de aprobación, programar ventanas para aplicar parches e implementar correcciones. Ese supuesto ha quedado obsoleto. Los datos de seguimiento del sector sugieren que, en el caso de las exposiciones más críticas, el tiempo promedio entre la divulgación de una vulnerabilidad y su explotación activa es ahora de solo unas horas, frente a las aproximadamente tres semanas de apenas 2025. Los modelos de inteligencia artificial (IA) de frontera, capaces de generar de forma autónoma exploits (N. del T.: código o técnica que aprovecha una vulnerabilidad de seguridad) funcionales a escala y a un costo insignificante, han cerrado esa brecha.1

Los modelos de IA —entre ellos Mythos/Fable de Anthropic, GPT-Cyber de OpenAI y Gemini de Google— representan un verdadero salto cualitativo. En lugar de limitarse a acelerar los flujos de trabajo de los ataques, facilitan el descubrimiento y la explotación de vulnerabilidades, y ponen estas capacidades al alcance de un grupo mucho más amplio de atacantes potenciales. Un análisis de McKinsey sugiere que las vulnerabilidades críticas nuevas para las que no hay parches disponibles representan ahora la mayoría de las exposiciones activas.

Más perspectivas de McKinsey en Español

Mire nuestra colección de artículos en Español y suscríbase a nuestro newsletter mensual en Español.

Navegue por la colección

Para las organizaciones, la pregunta no es si una vulnerabilidad será explotada antes de que pueda aplicarse un parche, sino cuántas vulnerabilidades serán explotadas. La IA de frontera es motivo de preocupación para los directores de seguridad (chief security officers, CSO) y los directores de información (chief information officers, CIO) porque permite ataques más eficaces y a una mayor velocidad que la de la toma de decisiones de las empresas (Gráfica 1). Desde esa perspectiva, plantea a las organizaciones un problema de modelo operativo, más que un problema tecnológico.

Latencia organizacional: El desafío oculto

Cuando se les pregunta qué les impide responder con mayor rapidez a las vulnerabilidades críticas de los sistemas, la mayoría de los líderes de seguridad rara vez señala a la tecnología en sí. Muchas organizaciones ya cuentan con herramientas de detección robustas, plataformas de gestión de parches y protocolos de respuesta a incidentes. Es posible responder con rapidez mediante entornos altamente estandarizados, arquitecturas de confianza cero y capacidades de despliegue como código. El mayor desafío radica en los procesos de toma de decisiones, la gobernanza y la coordinación operativa necesarios para traducir las capacidades técnicas en acciones con la rapidez necesaria. Consideremos lo que suele ocurrir cuando se descubre una vulnerabilidad crítica:

  • El área de seguridad de TI identifica la vulnerabilidad y evalúa su gravedad y los sistemas afectados. Esto puede tomar un día o más, dependiendo de la visibilidad de los activos en los sistemas heredados, las plataformas en la nube, las aplicaciones de software como servicio (software-as-a-service, SaaS) y los entornos de tecnología operativa, que rara vez están inventariados por completo.
  • El equipo de seguridad escala el incidente a la dirección de TI, que debe evaluar el impacto en el negocio antes de autorizar la aplicación del parche. Después, la dirección de TI debe consultar con los responsables de las aplicaciones, quienes gestionan los calendarios de lanzamiento y los periodos de congelamiento de cambios.
  • Es necesario probar la aplicación de parches tanto en el software de proveedores o disponible comercialmente como en el desarrollado internamente. Las organizaciones que aún gestionan una cantidad considerable de código personalizado o heredado —lo que incluye a la mayoría de las grandes empresas— suelen afrontar semanas de trabajo de validación antes de que una corrección pueda certificarse para su despliegue en producción.
  • Programar la ventana para aplicar el parche y conocer la ventana de lanzamiento exige que los líderes de TI se coordinen con las áreas de negocio. Al hacerlo, facilitan que las operaciones continúen con normalidad. Las plantas de manufactura no tienen que detener las líneas de producción para aplicar parches durante los periodos de mayor actividad, los hospitales no tienen que desconectar los sistemas clínicos durante las horas de atención a pacientes y las instituciones financieras pueden evitar realizar cambios durante los periodos de mayor volumen de transacciones.
  • El despliegue requiere la aprobación de un líder de gestión del cambio. En muchas organizaciones, esto exige pasar por un comité asesor de cambios que se reúne semanalmente.
  • Después de todo esto, los sistemas gestionados por proveedores y por terceros pueden operar con calendarios de aplicación de parches totalmente independientes sobre los que ningún equipo interno tiene control.

Esto no es una disfunción, sino la forma en que las grandes organizaciones están diseñadas para operar. Estos procesos existen para garantizar el tiempo de disponibilidad de los sistemas, gestionar el cumplimiento regulatorio, preservar la calidad del servicio y evitar las interrupciones operativas que pueden causar los parches que no se han probado de forma adecuada. Sin embargo, la IA de frontera cambia las reglas del juego. Las vulnerabilidades que antes podían permanecer expuestas durante semanas ahora deben atenderse en cuestión de horas para impedir que los atacantes causen daños. La arquitectura organizacional se ha convertido directamente en un riesgo para la seguridad.

Un desafío común es que nadie es responsable de la velocidad de la toma de decisiones. TI es responsable del proceso de aplicación de parches; las áreas de negocio, de las decisiones sobre los tiempos de inactividad; el área legal, de los plazos de divulgación; compras, de las relaciones con los proveedores; operaciones, de la continuidad de la producción; y seguridad, de la evaluación de riesgos. Ninguna función por sí sola tiene la autoridad, la visibilidad y el mandato necesarios para mover a la empresa al ritmo que exige la amenaza. Como resultado, una decisión crítica que debería tomar horas termina tardando mucho más.

La respuesta desde el modelo operativo: Rediseñar las decisiones

Las organizaciones que se desenvuelven con mayor eficacia en el panorama de la ciberseguridad comparten una característica que no tiene relación con su conjunto de herramientas de seguridad. Se distinguen por sus modelos operativos y, en concreto, por la manera en que han rediseñado la estructura de la visibilidad continua del riesgo, la gobernanza de la defensa habilitada por IA y la arquitectura de la toma de decisiones organizacional bajo presión de tiempo.

En la mayoría de los casos, estas organizaciones han logrado lo que llamamos autonomía gobernada.

Es decir, un modelo operativo cibernético en el que la IA se encarga del trabajo de alto volumen y sujeto a presiones de tiempo que implican el monitoreo continuo y la remediación rutinaria, mientras que el juicio humano rige las amenazas nuevas, las decisiones estratégicas sobre riesgos y todo aquello que tenga un impacto material en el negocio. Lograr la autonomía gobernada depende de tres imperativos de diseño, cada uno de los cuales es organizacional antes que técnico.

La visibilidad continua del riesgo es un requisito básico

El primer imperativo de diseño consiste en hacer que la organización pase de los escaneos periódicos y los ciclos de remediación programados a una conciencia operativa continua, centrada en lo que más importa. Esto exige una decisión explícita sobre el alcance y la secuencia.

El punto de partida práctico no es aspirar a tener visibilidad en tiempo real en toda la empresa. Esa ambición fracasa sistemáticamente porque el alcance es demasiado amplio y el cambio necesario resulta demasiado disruptivo. En cambio, las empresas líderes comienzan por definir una organización mínima viable, es decir, el núcleo irreductible de sistemas, procesos y activos cuya interrupción supondría una amenaza para su existencia. Para un banco, podrían ser el procesamiento de pagos, los sistemas bancarios centrales y los reportes regulatorios. Para un fabricante, podrían ser las líneas de producción y los sistemas de tecnología operativa (operational technology, OT) que las controlan. Para un hospital, podrían ser los sistemas clínicos y la infraestructura crítica para preservar la vida.

Al concentrarse primero en la visibilidad casi en tiempo real y el escaneo continuo del núcleo, las organizaciones pueden crear un perímetro defendible en torno a lo que más importa. Paralelamente, pueden reducir la superficie de ataque, retirando activos innecesarios expuestos al exterior, racionalizando las dependencias de código abierto, eliminando credenciales obsoletas y reforzando la segmentación de la red. En una institución financiera global, los líderes descubrieron que priorizar el escaneo mediante grandes modelos de lenguaje en su banco mínimo viable produjo una reducción sustancial de la exposición en torno a sus activos de mayor valor, con mayor rapidez y a un costo menor que los enfoques anteriores.

Es importante destacar que reducir la superficie de ataque no es solo un ejercicio técnico. Requiere decisiones de negocio sobre qué activos retirar, qué interfaces externas cerrar y qué integraciones con terceros restringir. Esas decisiones involucran simultáneamente a TI, operaciones, los responsables del negocio y el área legal. La velocidad de la alineación organizacional determina la velocidad con la que se reduce la superficie de ataque.

La gobernanza de la defensa habilitada por IA debe ser una arquitectura fundamental

El segundo imperativo de diseño consiste en desplegar la IA defensiva como la arquitectura operativa de las operaciones de seguridad. Tres capas distintas definen esa arquitectura, y cada una debe diseñarse como un flujo de trabajo integral “agentificado”, en lugar de ensamblarse a partir de soluciones independientes de distintos proveedores:

  • Búsqueda de amenazas y descubrimiento de rutas de ataque: Los modelos de IA pueden realizar análisis continuos del encadenamiento de rutas de ataque en entornos complejos y heterogéneos —correlacionando señales entre sistemas de TI, OT, en la nube y de terceros— para revelar exposiciones y priorizar las tareas de remediación pendientes en función de la posibilidad real de explotación y de la exposición del valor para el negocio, en lugar de basarse en puntuaciones genéricas de gravedad. Esto es importante porque los sistemas habituales de puntuación de vulnerabilidades no distinguen entre una vulnerabilidad en un entorno de pruebas y esa misma vulnerabilidad en un sistema situado a tres pasos de “las joyas de la corona”. La priorización habilitada por IA puede hacer esa distinción de forma continua y a escala.
  • Remediación de vulnerabilidades y gestión de riesgos de terceros: Para las organizaciones que desarrollan y mantienen una cantidad considerable de software —es decir, la mayoría de las grandes instituciones financieras, empresas industriales y fabricantes con uso intensivo de tecnología—, el modelado de amenazas asistido por IA, las pruebas de resistencia automatizadas durante el ciclo de vida del desarrollo de software y las sugerencias de parches generadas por IA pueden reducir drásticamente el tiempo que transcurre entre la identificación de una vulnerabilidad y la disponibilidad de una corrección probada. Esto aborda uno de los cuellos de botella más persistentes: el tiempo que tarda un equipo de desarrollo en comprender, reproducir y corregir una vulnerabilidad en código que quizá no haya tocado en años.

Los componentes de software de código abierto pueden convertirse en un riesgo debido a la facilidad con la que los atacantes pueden identificar o integrar vulnerabilidades y, con el tiempo, utilizarlas llevar a cabo ataques (por ejemplo, ataques en etapas posteriores). Las organizaciones deben generar transparencia interna sobre dónde y cómo se despliegan estos componentes y, después, realizar escaneos de vulnerabilidades basados en IA de frontera —incluso antes del despliegue— y desarrollar parches con asistencia de IA cuando corresponda. En el caso del software comercial, es necesario actualizar los acuerdos de nivel de servicio para la remediación con los proveedores externos para que abarquen las vulnerabilidades encadenadas. Por último, debe fortalecerse la gestión de las consecuencias.

  • Respuesta a incidentes y operaciones de seguridad: La IA puede automatizar el triaje, acelerar la secuencia de contención y coordinar la respuesta multifuncional sin tener que esperar a que haya un responsable humano disponible para tomar una decisión. Las organizaciones líderes están preautorizando a agentes de IA para ejecutar acciones de respuesta específicas y acotadas, como aislar sistemas, revocar credenciales y aplicar controles compensatorios, todo ello dentro de salvaguardas definidas. En el caso de las respuestas de bajo riesgo, la revisión humana se realiza después de la acción. Esto no es seguridad autónoma; es una seguridad gobernada para responder con rapidez. Los procesos de continuidad del negocio y de gestión de crisis deben volver a ponerse a prueba frente a esa realidad, con una visión clara y acordada de antemano de la organización mínima viable que debe seguir funcionando mientras todo lo demás permanece en cuarentena.

El objetivo en las tres capas es garantizar que el juicio humano se reserve para las decisiones que realmente lo requieren y que las acciones de remediación rutinarias sujetas a presiones de tiempo no tengan que esperar.

La arquitectura de la toma de decisiones organizacional debe optimizarse para operar bajo presión de tiempo

El tercer imperativo de diseño, y el más subestimado, consiste en rediseñar la propia arquitectura de toma de decisiones. La realidad es que la mayoría de las organizaciones todavía gestionan la ciberseguridad mediante estructuras de gobernanza diseñadas para otra época. Existe la creencia generalizada de que el riesgo de un cambio innecesario o mal controlado es mayor que el de un cambio que tarda demasiado. Los comités asesores de cambios, los comités directivos de seguridad, los grupos de trabajo multifuncionales y las cadenas de escalamiento que atraviesan varias funciones de la C-suite aceptan instintivamente esa premisa. Pero cuando una vulnerabilidad queda expuesta a una explotación activa acelerada y habilitada por IA, la demora se convierte en el riesgo mayor.

Las organizaciones líderes están rediseñando los procesos de toma de decisiones en torno a una célula de respuesta multifuncional, es decir, un equipo pequeño y facultado, con un único responsable de la toma de decisiones que cuenta con autoridad delegada por el CSO para anular los procesos estándar de gestión del cambio ante amenazas activas confirmadas. La célula realiza un ciclo diario de triaje y es responsable de una lista de vulnerabilidades pendientes que se actualiza en tiempo real. Cuenta con protocolos de respuesta preautorizados que puede ejecutar sin necesidad de escalar la decisión. Además, tiene un enlace ejecutivo que convierte los avances técnicos en información visible para el consejo de administración cada 24 horas. Los roles están claramente definidos y la autoridad para tomar decisiones se asigna de manera explícita, en lugar de diluirse.

Así, el imperativo de diseño clave es que la autoridad para tomar decisiones esté verdaderamente centralizada. Una institución financiera reestructuró la gobernanza de su gestión de parches después de un incidente en el que una vulnerabilidad crítica permaneció sin parche durante 11 días porque ningún equipo contaba con la visibilidad técnica y la autoridad de negocio necesarias para anular un periodo de congelamiento de cambios en producción. El modelo reestructurado otorgó al líder de su célula de respuesta autoridad explícita delegada por el CSO para actuar, y los reportes posteriores a la acción sustituyeron a la aprobación previa ante amenazas activas confirmadas. Los plazos de remediación de las vulnerabilidades críticas se redujeron significativamente.

Una empresa farmacéutica adoptó un enfoque similar ante uno de los cuellos de botella más difíciles de resolver: la acumulación de actualizaciones pendientes en los entornos de investigación y desarrollo (I+D), donde los parches de seguridad suelen quedar relegados frente a los calendarios de desarrollo de productos. La solución requirió un programa de cambio liderado por el negocio (no por la función de TI), que estableció formalmente una secuencia que da prioridad a la remediación en los entornos de I+D y otorgó a la función de seguridad autoridad permanente para anular los calendarios de desarrollo durante amenazas activas. La intervención organizacional ayudó a abordar la causa raíz de una manera que la tecnología por sí sola no podía lograr.

Un corolario de los tres imperativos es que el rediseño de la gobernanza debe extenderse a los modelos operativos de crisis más amplios. Las organizaciones líderes están invirtiendo en estructuras de respuesta que abarcan distintos ámbitos y pueden coordinar simultáneamente acciones en las dimensiones cibernética, física y operativa. Por ejemplo, una empresa europea del sector aeroespacial y de defensa creó un centro de inteligencia de seguridad que integró su centro de operaciones de ciberseguridad, las operaciones de seguridad física y la inteligencia externa sobre amenazas en una visión unificada y en tiempo real. La empresa quería hacer posible una respuesta coordinada a los ataques que combinan vectores digitales y físicos. Una aseguradora europea consolidó sus capacidades de resiliencia bajo un único responsable de resiliencia. Estableció un consejo de resiliencia trimestral a nivel del consejo de administración, al reconocer que los silos organizacionales entre la ciberseguridad, la continuidad del negocio y la seguridad física eran, en sí mismos, vulnerables.

La autonomía gobernada en la práctica

La autonomía gobernada forma parte de la arquitectura de resiliencia más amplia de una organización, que opera en seis dimensiones: finanzas, operaciones, tecnología, organización, reputación y modelo de negocio.2

Un CSO que solo es responsable de la dimensión tecnológica, sin conexiones explícitas con la resiliencia organizacional y operativa, no puede implementar con éxito la autonomía gobernada. El modelo requiere una responsabilidad compartida en los miembros de la C-suite. El proceso de implementación debe seguir un patrón consistente, por lo general en tres fases, cada una de las cuales desarrolla el músculo organizacional que requiere la siguiente.

Antes de examinar cómo funciona el modelo, vale la pena preguntarse en qué posición se encuentra actualmente su organización. La mayoría de las empresas con las que trabajamos se encuentran en una de estas tres posiciones:

  • Cuentan con herramientas de seguridad sólidas, pero la autoridad para tomar decisiones está dispersa y nadie está facultado para actuar con rapidez (la situación más común).
  • Parte de la toma de decisiones está centralizada, pero conectada con las operaciones habilitadas por IA.
  • La organización está comenzando a desplegar agentes de IA en un entorno donde aún no existe la arquitectura de gobernanza necesaria para gestionarlos.

Cada posición tiene una acción de máxima prioridad diferente, que puede ser, por ejemplo, el despliegue de tecnología o el cambio organizacional. El modelo de tres fases describe el camino desde la primera posición hasta la tercera, así como las decisiones organizacionales que determinan si una organización avanza (Gráfica 2).

En la implementación de la autonomía gobernada, se aplican tres fases generales:

  • Primero, el modelo operativo no solo hace posible el despliegue de la IA, sino que gobierna su uso en toda la organización. Los umbrales de precisión, los procesos de calibración de la confianza, la revocación automática de la autoridad autónoma ante errores sistemáticos y los requisitos de reporte posterior a la acción pueden garantizar que, a medida que se expande la automatización, también lo haga la responsabilidad humana. Esto es lo que significa la autonomía en la práctica: no limita el potencial de la IA; la arquitectura permite utilizarla de manera segura. Por ejemplo, un agente de aplicación de parches (orquestación) con un amplio nivel de acceso y autonomía para desplegarlos, de modo que pueda responder a misma velocidad que las amenazas, también debe tratarse como un activo crítico que requiere salvaguardas para evitar que sea comprometido o que su comportamiento se desvíe.
  • Segundo, el modelo operativo está diseñado para desarrollar la capacidad organizacional antes de ampliar la autoridad de la IA. La primera fase, o movilización humano, consiste en centralizar la toma de decisiones humana y establecer disciplina en la gobernanza de la IA. Las organizaciones que omiten la primera fase e intentan desplegar agentes de IA en un entorno donde la autoridad para tomar decisiones sigue dispersa generan, de manera sistemática, sistemas de IA que formulan recomendaciones sobre las que nadie actúa.
  • Tercero, y lo más importante, el modelo operativo requiere el respaldo del CEO y del consejo de administración. Nuestra experiencia en distintas implementaciones muestra que las organizaciones que tratan la autonomía gobernada como un programa de seguridad se estancan en la primera fase. Los cuellos de botella son decisiones de negocio relacionadas con el tiempo de inactividad de la producción, la autoridad para la gestión del cambio, la priorización del desarrollo y las obligaciones de los proveedores, que la función de seguridad no puede resolver de manera unilateral. Las organizaciones que tratan la autoridad gobernada como un programa de resiliencia empresarial, con el respaldo explícito de la alta dirección y la gobernanza del consejo de administración, tienen más probabilidades de avanzar a lo largo de las tres fases.

La autonomía gobernada puede ayudar a los líderes a determinar quién decide qué, con qué autoridad, en qué plazo, conforme a qué reglas y ante quién rinde cuentas. Es la arquitectura operativa dentro de la cual funciona la tecnología. Sin ella, las mejores herramientas del mercado quedan atrapadas en las mismas cadenas de aprobación de comités que eran el problema desde un principio.

Disciplina del modelo operativo con plazos comprimidos

La disciplina del modelo operativo descrita aquí aborda la dimensión más urgente del desafío. Pero ya se está formando una segunda ola de complejidad. Desplegar sistemas de IA agéntica a escala introduce una nueva categoría de requisitos fundamentales —entre ellos los límites de acceso a los datos, los controles de identidad y los límites de comportamiento—, que deben definirse y aplicarse antes de que se pueda confiar en que los agentes autónomos actúen. Establecer correctamente esas bases es una decisión de gobernanza con consecuencias para el consejo de administración.

El mismo principio se aplica a los nuevos aspectos económicos de la seguridad impulsada por IA. Dicho de otro modo, el costo por consulta que supone ejecutar continuamente modelos grandes para la detección de amenazas, la remediación y la respuesta está introduciendo un tipo de presión presupuestaria que los modelos tradicionales de gasto en seguridad nunca fueron diseñados para absorber.

Quizá lo más trascendental es que el propio rol del CSO se está redefiniendo. El CSO agéntico del futuro cercano será menos una autoridad técnica y más un arquitecto de la autonomía gobernada a escala, que establecerá políticas para sistemas de IA que actúan en lugar de asesorar y rendirá cuentas por decisiones tomadas a velocidades que ningún ser humano puede supervisar directamente. Estos son los desafíos que darán forma a la próxima fase de este trabajo.


Las organizaciones que tengan el mejor desempeño en ciberseguridad durante los próximos tres a cinco años serán aquellas que actúen pronto para rediseñar los derechos de decisión, desarrollar una gobernanza capaz de operar a la velocidad de las máquinas, invertir en la disciplina necesaria para gobernar la remediación autónoma mediante IA y vincular su ciberresiliencia directamente con los resultados de negocio que esta protege. Entre ellos se encuentran el tiempo de disponibilidad de las operaciones de manufactura, la confianza de los clientes, la posición ante los reguladores y la continuidad. El presupuesto de seguridad importará mucho menos que la claridad del modelo operativo.

La implicación va más allá de la ciberseguridad. La IA está comprimiendo los plazos de gestión en todas las funciones de la empresa. Las organizaciones que desarrollen la capacidad de tomar decisiones de alto impacto con mayor rapidez, con mejor información y bajo presión de tiempo trasladarán esa ventaja al conjunto de sus operaciones. Pero la ciberseguridad es el ámbito donde esta compresión está ocurriendo primero, donde hay más juego y donde existe menor tolerancia a la demora. Por ello, es el lugar indicado para desarrollar el músculo del modelo operativo que exigirá la próxima década de liderazgo empresarial.

Explore a career with us