Google Cloud Lleva la defensa frente a amenazas de IA a la sala de juntas

Google Cloud ha llevado la defensa frente a amenazas de IA a la sala de juntas, sosteniendo que los ataques automatizados ya avanzan más rápido de lo que muchas organizaciones pueden evaluar y contener.

Esta advertencia importa más allá del último ciclo de google news. Google pide a los directores que traten el riesgo cibernético a velocidad de máquina como una cuestión de resiliencia operativa, no como otro asunto técnico para el CISO.

La posición de la compañía se basa en una creciente brecha de velocidad. Los atacantes pueden usar IA para identificar vulnerabilidades, generar ingeniería social convincente y automatizar partes de una intrusión. Los defensores a menudo siguen dependiendo de revisiones manuales, herramientas desconectadas y cadenas de aprobación que operan a velocidad humana.

Google también tiene una respuesta comercial. Su plataforma Google AI Threat Defense combina tecnología de Gemini, Mandiant, Google Threat Intelligence, Google Security Operations y Wiz. Google afirma que el sistema puede priorizar exposiciones y acelerar la remediación en código, infraestructura en la nube, identidades y aplicaciones en ejecución.

Esta combinación genera la tensión central. Los consejos necesitan mejores defensas contra ataques asistidos por IA, pero deben decidir cuánta autoridad de seguridad delegar en otro sistema de IA.

Microsoft, Amazon Web Services, Palo Alto Networks, CrowdStrike y otros proveedores de seguridad persiguen sus propias estrategias de automatización. Por tanto, el argumento de Google es a la vez una advertencia y una apuesta por definir la plataforma de seguridad empresarial para la era agéntica.

Lo que Google Cloud cambió realmente

Google Cloud está empaquetando la seguridad de IA como un modelo operativo continuo, en lugar de como una colección de herramientas aisladas de detección.

La compañía presentó Google AI Threat Defense el 27 de mayo de 2026. Google lo describe como un sistema siempre activo, diseñado para supervisar riesgos y ayudar a detener amenazas impulsadas por IA antes de que afecten a las operaciones empresariales.

Su diseño abarca la superficie de ataque desde la creación de software hasta la producción. La plataforma examina código, configuraciones en la nube, identidades, cargas de trabajo desplegadas e inteligencia de amenazas. Después utiliza ese contexto para identificar las exposiciones que presentan el mayor riesgo práctico.

Esta distinción importa porque los escáneres de vulnerabilidades generan regularmente más hallazgos de los que los equipos de seguridad pueden abordar. Una calificación técnica crítica no siempre significa que una falla sea accesible, explotable o esté conectada a datos sensibles.

Google afirma que su sistema utiliza un contexto organizativo más amplio para determinar qué hallazgos merecen atención. La propiedad de los activos, las relaciones entre aplicaciones, los permisos de identidad, las rutas de exposición y la inteligencia de amenazas activa pueden influir en esa clasificación.

El lanzamiento de la defensa frente a amenazas de la compañía presenta cuatro etapas conectadas. Su objetivo es proteger el desarrollo de software, analizar y priorizar vulnerabilidades, defender aplicaciones desplegadas y mejorar la detección y la respuesta.

Gemini proporciona razonamiento sobre los datos de seguridad. Mandiant aporta conocimiento sobre incidentes y experiencia de primera línea. Google Threat Intelligence añade información sobre adversarios, vulnerabilidades y campañas activas.

Wiz incorpora datos sobre la postura de seguridad en la nube y la exposición a la cartera más amplia. Google completó su estrategia de adquisición en torno a Wiz para reforzar la visibilidad en entornos multinube, donde las cargas de trabajo y las identidades rara vez se mantienen dentro de un solo proveedor.

CodeMender aborda las vulnerabilidades de software antes en el desarrollo. Google afirma que puede ayudar a encontrar, validar y reparar fallas antes de que las aplicaciones lleguen a producción.

Estos componentes ya tenían valor por separado. El cambio es el intento de Google de conectarlos mediante una arquitectura de seguridad única y una capa compartida de priorización asistida por IA.

Este enfoque de plataforma también refleja la economía de las operaciones de seguridad modernas. Las empresas han acumulado numerosas herramientas, pero cada producto puede generar otra cola de alertas. Más detección no produce automáticamente una contención más rápida.

La propuesta de Google es que el contexto puede reducir esa carga. Un sistema de IA puede examinar relaciones que, de otro modo, los analistas tendrían que reconstruir entre tickets, paneles, repositorios y sistemas de identidad.

El ejemplo práctico es una aplicación vulnerable conectada a una cuenta de servicio privilegiada. Un escáner podría informar de la falla de software mientras otro producto señala permisos excesivos. Una tercera plataforma podría detectar explotación activa.

Si esos hallazgos permanecen separados, los analistas deben conectarlos manualmente. Google AI Threat Defense está diseñado para ensamblar esa cadena y elevar el riesgo combinado.

La plataforma no elimina la necesidad de especialistas. Alguien todavía debe decidir si una corrección propuesta es segura, si una aplicación puede tolerar tiempo de inactividad y si la automatización ha interpretado correctamente el contexto empresarial.

Sin embargo, Google ha cambiado la conversación de compra. Ya no ofrece IA meramente como un asistente que resume alertas. Está posicionando la IA como la capa de coordinación para la defensa empresarial.

Por qué las noticias de Google sobre seguridad de IA ahora pertenecen a la agenda del consejo

La cuestión a nivel de consejo no es si los atacantes usan IA. Es si la empresa puede tomar decisiones defendibles dentro de una ventana de respuesta cada vez más reducida.

El informe Threat Horizons H1 2026 de Google Cloud afirma que el intervalo entre la divulgación pública de una vulnerabilidad y su explotación activa se redujo de semanas a días durante la segunda mitad de 2025.

El informe también describe un intento de intrusión en la cadena de suministro asistido por IA. Los actores de amenazas utilizaron modelos de lenguaje grandes para automatizar la recolección de credenciales y avanzar desde un entorno de desarrollador hacia el acceso administrativo a la nube.

Según Google, los actores abusaron de la confianza asociada a OpenID Connect, un protocolo que permite a los servicios verificar identidades sin intercambiar contraseñas directamente. La actividad se desarrolló en menos de 72 horas.

Este caso no significa que una IA autónoma completara una intrusión entera sin participación humana. Muestra que los atacantes pueden utilizar modelos para acelerar tareas individuales dentro de una campaña más amplia.

Los demás hallazgos del informe refuerzan un problema menos futurista. El compromiso de identidades siguió siendo central en los incidentes en la nube, mientras que el robo de datos continuó siendo un objetivo principal.

Los hallazgos sobre amenazas en la nube de Google indican que los problemas de identidad permitieron el acceso inicial en el 83% de los incidentes examinados que involucraban grandes entornos de nube y software como servicio. Los actores de amenazas apuntaron a datos en el 73% de los incidentes relacionados con la nube.

Estas cifras proceden de intervenciones de respuesta y defensa de Mandiant durante la segunda mitad de 2025. Representan la combinación de casos observada por Google, no todas las brechas a nivel mundial.

Aun así, destacan por qué un consejo no puede tratar la seguridad de IA únicamente como un ejercicio de gobernanza de modelos. El sistema vulnerable podría ser un agente, pero la debilidad decisiva puede seguir siendo una identidad con privilegios excesivos, una aplicación expuesta o una dependencia sin parchear.

Los directores ya son responsables de supervisar riesgos empresariales comparables. La Comisión de Bolsa y Valores de Estados Unidos exige a las empresas públicas describir la supervisión del consejo sobre las amenazas de ciberseguridad y el papel de la dirección en la gestión de riesgos cibernéticos materiales.

Por lo general, un incidente material debe divulgarse en un plazo de cuatro días hábiles después de que la empresa determine que es material. La norma centra la atención en el impacto empresarial, la gobernanza y la calidad de las decisiones, más que en la novedad técnica.

Por tanto, las normas de divulgación de la SEC dan peso regulatorio al argumento de Google. Los directores necesitan información suficiente para comprender el posible daño financiero y operativo antes de que un incidente alcance la etapa de divulgación.

Los agentes de IA complican esa responsabilidad. Un agente puede acceder a documentos, llamar a herramientas de software, crear código o actuar mediante las credenciales de un usuario. Su identidad operativa puede llegar a ser más importante que el modelo subyacente.

Un empleado normalmente opera dentro de procesos establecidos de incorporación, revisión de accesos y desvinculación. Un agente de IA podría ser creado rápidamente por una unidad de negocio, conectarse a varios sistemas y mantenerse en funcionamiento sin una supervisión equivalente.

Esto genera el riesgo de “agentes en la sombra”. El término describe agentes de IA desplegados fuera de la visibilidad o el control de los equipos centrales de seguridad.

Un consejo no necesita un catálogo de todos los agentes. Necesita pruebas de que la dirección sabe qué agentes pueden acceder a sistemas sensibles, quién es responsable de ellos y qué límites se aplican a sus acciones.

También necesita medidas de resiliencia significativas. El número de alertas detectadas dice poco a los directores sobre si la organización puede sobrevivir a un ataque.

Las preguntas más útiles se refieren a la exposición y la recuperación. ¿Cuántos sistemas críticos dependen de identidades sin autenticación resistente al phishing? ¿Con qué rapidez puede revocarse el acceso privilegiado? ¿Puede la organización reconstruir un ataque si un adversario elimina los registros habituales?

El mensaje de Google traslada la ciberseguridad de la titularidad de controles al rendimiento operativo. Puede existir una política mientras la aplicación de parches sigue siendo lenta, las identidades conservan privilegios excesivos y la evidencia de incidentes permanece incompleta.

Para los directores, esto convierte la defensa de IA en una cuestión de asignación de capital. Financiar otro panel tiene un valor limitado si la empresa no puede conectar los hallazgos con activos críticos para el negocio.

La pregunta relevante es si la inversión en seguridad reduce la interrupción esperada. Esto exige que la dirección traduzca la exposición técnica en posible tiempo de inactividad, pérdida de datos, obligaciones legales y costes de recuperación.

Google News destaca una carrera entre el ataque automatizado y la defensa automatizada

El principal adversario de Google no es otro proveedor de nube. Es el modelo de seguridad a velocidad humana que aún rige muchas respuestas empresariales.

El pronóstico de Google para 2026 anticipa un uso más amplio de IA en todo el ciclo de vida del ataque. Los actores de amenazas pueden usar modelos para redactar señuelos, investigar objetivos, modificar código malicioso y analizar información robada.

La IA agéntica eleva las apuestas porque un agente puede perseguir un objetivo a lo largo de varios pasos. Puede seleccionar herramientas, actuar sobre los resultados y ajustar su siguiente movimiento con menor supervisión humana directa.

Google espera que los defensores respondan con un “SOC agéntico”. Un centro de operaciones de seguridad, o SOC, es el equipo y la tecnología responsables de supervisar y responder a amenazas.

En un SOC agéntico, los sistemas de IA investigarían alertas, recopilarían pruebas, recomendarían contención y ejecutarían tareas de respuesta seleccionadas. Los analistas humanos supervisarían las decisiones de mayor riesgo.

El pronóstico de seguridad de Google plantea esto como una carrera armamentística. Los atacantes ganan velocidad y escala, mientras que los defensores utilizan agentes para mejorar la capacidad de los analistas.

El argumento a favor de la automatización es sencillo. Un analista humano no puede inspeccionar manualmente cada evento de identidad, cambio de código, vulnerabilidad y configuración en la nube generados en una gran empresa.

Un sistema de IA puede correlacionar esas señales más rápido. También puede mantener la atención en un mayor número de investigaciones simultáneas.

Sin embargo, la velocidad por sí sola no equivale a una seguridad sólida. Una respuesta automatizada puede interrumpir la producción, revocar accesos legítimos o priorizar la vulnerabilidad equivocada cuando su contexto es incompleto.

Ese riesgo convierte la autoridad delegada en el problema central de gobernanza. Cuantas más acciones pueda realizar un agente defensivo, mayor será su potencial para detener un ataque. Esa misma autoridad aumenta el daño derivado de una decisión incorrecta o de un agente comprometido.

Por lo tanto, las organizaciones necesitan límites de autonomía definidos. Un agente podría recopilar pruebas automáticamente, pero requerir aprobación antes de deshabilitar una cuenta. Podría aislar una carga de trabajo de prueba mientras escala la acción contra un sistema de ingresos.

Estos límites deben reflejar el impacto empresarial, no solo la gravedad técnica. Suspender una cuenta de servicio puede detener todo el flujo de trabajo de un cliente, mientras que otra cuenta puede deshabilitarse sin una interrupción visible.

La estrategia de plataforma de Google intenta aportar este contexto. Wiz puede mapear la exposición en la nube, Mandiant puede proporcionar conocimiento sobre incidentes y Gemini puede razonar a partir de los hallazgos.

Microsoft tiene un incentivo similar para conectar datos de seguridad a través de sus productos de nube, identidad, endpoints y productividad. Amazon Web Services está añadiendo asistencia de IA a la seguridad y las operaciones en la nube. Los proveedores especializados están desarrollando funciones autónomas de investigación y remediación en torno a sus plataformas existentes.

Este contexto competitivo importa porque las empresas rara vez operan en un único entorno de seguridad. Una compañía puede utilizar identidades de Microsoft, infraestructura de AWS, herramientas de productividad de Google y productos de seguridad de varios proveedores.

Un defensor automatizado solo puede razonar sobre la información a la que tiene acceso. Las brechas entre plataformas pueden ocultar la ruta que un atacante utiliza para moverse de un sistema a otro.

Google sostiene que un contexto amplio otorga a su plataforma una ventaja. Esa afirmación requerirá pruebas en entornos de clientes heterogéneos, no solo en infraestructura gestionada por Google.

El peligro es sustituir la fragmentación de alertas por fragmentación de la automatización. Varios agentes defensivos podrían investigar el mismo evento, recomendar acciones contradictorias u operar con datos de activos inconsistentes.

Por ello, los consejos de administración deberían preguntar cómo coordina la dirección los sistemas automatizados. Una arquitectura responsable necesita una jerarquía clara de decisiones, pruebas compartidas y registros que muestren por qué se produjo cada acción relevante.

Ese registro cobra importancia durante la revisión de incidentes. Si un agente bloquea el acceso, corrige código o modifica una política de nube, los investigadores deben poder reconstruir el razonamiento y las entradas que motivaron la acción.

Los equipos pueden respaldar ese proceso manteniendo una base de conocimiento de ingeniería con capacidad de búsqueda. Los manuales operativos, las decisiones de arquitectura, los registros de propiedad y las pruebas de incidentes deben seguir siendo accesibles durante una respuesta que evoluciona con rapidez.

Google afronta el verdadero reto de demostrar que su automatización reduce la carga operativa sin ocultar decisiones trascendentes. Un sistema que actúa más rápido pero no puede explicar sus pruebas puede crear otro problema de gobernanza.

La disyuntiva de la automatización que los consejos no pueden delegar

La defensa con IA necesita permiso para actuar, pero cada permiso adicional amplía el sistema que la empresa debe proteger.

Las afirmaciones de Google sobre su plataforma deberían evaluarse como declaraciones del proveedor hasta que los clientes publiquen resultados operativos independientes. La medida relevante no es cuántos hallazgos puede resumir Gemini.

Los consejos necesitan pruebas de que el sistema reduce la exposición, acelera una remediación segura y mejora la recuperación. Estos resultados deberían medirse sin excluir los incidentes que la automatización no detectó.

Los falsos positivos son una preocupación. Un sistema automatizado puede inferir que un comportamiento legítimo es malicioso, especialmente cuando una aplicación cambia de forma repentina o los usuarios trabajan fuera de los patrones establecidos.

Los falsos negativos son igualmente importantes. Un modelo puede ofrecer una explicación segura de sí misma mientras pasa por alto a un atacante que entiende su lógica de detección.

Los adversarios también pueden atacar la capa de IA. La inyección de prompts consiste en instrucciones ocultas o maliciosas diseñadas para hacer que un sistema de IA ignore sus reglas previstas.

Si un agente defensivo lee registros no confiables, comentarios de código, tickets o páginas web, los atacantes podrían insertar instrucciones en esas entradas. El agente necesita controles que separen las pruebas de los comandos.

El envenenamiento de datos plantea otra amenaza. Los atacantes pueden manipular la información utilizada para entrenar u orientar un modelo, debilitando sus conclusiones o desviando la atención de actividades maliciosas.

Un sistema autónomo también se convierte en una identidad con privilegios. Necesita acceso a telemetría de seguridad, inventarios de activos, repositorios y herramientas de respuesta.

Comprometer esa identidad podría dar a un atacante un mapa de las defensas empresariales. Unos permisos de respuesta excesivos también podrían proporcionar una vía para deshabilitar sistemas o destruir pruebas.

El National Institute of Standards and Technology considera estas cuestiones relacionadas, pero distintas. Su Cyber AI Profile preliminar abarca la protección de sistemas de IA, el uso de IA para la defensa y la frustración de ataques habilitados por IA.

Ese Cyber AI Profile está organizado en torno al NIST Cybersecurity Framework. Ofrece a las organizaciones una referencia neutral respecto a proveedores para examinar las afirmaciones de Google sobre su plataforma y sus propios controles.

El trabajo de NIST es valioso porque la seguridad de la IA atraviesa varios límites. Las empresas deben proteger el modelo, la aplicación circundante, la canalización de datos, las identidades y la infraestructura que ejecuta las acciones.

Ningún producto individual puede resolver todas esas capas. Google AI Threat Defense puede ayudar a conectarlas, pero los clientes siguen controlando la arquitectura de las aplicaciones, los permisos, la gestión de cambios y la planificación de recuperación.

También existe un riesgo de concentración. Una empresa que depende de un único proveedor para infraestructura en la nube, inteligencia de amenazas, análisis de seguridad y respuesta automatizada obtiene integración.

También crea una dependencia mayor de la disponibilidad de ese proveedor, sus supuestos de detección y su hoja de ruta de producto. Un fallo en un plano de control compartido puede afectar a varias capas a la vez.

La compatibilidad multicloud puede reducir parte de esa dependencia, pero solo si funciona con suficiente profundidad como para aplicar controles coherentes. La visibilidad básica no equivale a una respuesta fiable entre proveedores.

Los consejos deberían solicitar pruebas específicas antes de ampliar la autoridad de la automatización. La dirección debería mostrar qué acciones puede realizar el agente, qué sistemas quedan excluidos y cómo cambian las aprobaciones durante una emergencia.

Los responsables de seguridad también deberían probar los modos de fallo. ¿Qué ocurre cuando la inteligencia de amenazas se retrasa, los datos de identidad están incompletos o el servicio de modelos deja de estar disponible?

Un diseño seguro necesita una alternativa manual. Los analistas deberían poder pausar la automatización, revertir acciones y continuar una investigación utilizando pruebas preservadas.

Las organizaciones deberían probar esos controles mediante ejercicios. Una discusión de mesa puede revelar responsabilidades poco claras, pero se necesitan simulaciones técnicas para medir si los sistemas se comportan como se espera.

La evaluación debería incluir intentos de inyección de prompts, pruebas envenenadas, credenciales de servicio comprometidas y recomendaciones contradictorias de herramientas separadas.

Los directores no necesitan aprobar manuales operativos individuales. Deberían verificar que la dirección ha establecido umbrales de riesgo, pruebas independientes y responsables identificables.

También deberían evitar tratar las métricas generadas por IA como objetivas. Si la misma plataforma identifica los riesgos, los prioriza, los remedia e informa del éxito, la validación independiente se vuelve esencial.

La advertencia de Google es creíble porque la velocidad de los ataques está aumentando. Su respuesta de producto aún necesita pruebas de clientes de que la automatización mejora la seguridad bajo restricciones operativas reales.

Lo que los consejos deberían vigilar durante los próximos tres meses

La próxima fase se decidirá por los resultados de los clientes, la integración competitiva y las pruebas de gobernanza, más que por otra ronda de anuncios sobre seguridad de IA.

La primera señal es evidencia medible de despliegues de Google AI Threat Defense. Los clientes deberían informar si la plataforma reduce el tiempo entre el descubrimiento de una vulnerabilidad, su priorización y una remediación segura.

Los resultados útiles incluirían cambios en la duración de la exposición, el tiempo de investigación y el rendimiento de recuperación. El volumen de alertas por sí solo no demostraría que el sistema mejoró la seguridad.

Los estudios de caso independientes reforzarían la posición de Google si incluyen entornos multicloud complejos. La evidencia limitada a demostraciones controladas dejaría sin resolver la afirmación central sobre integración.

Los consejos también deberían buscar detalles sobre la aprobación humana. Un resultado de cliente tiene más valor cuando los lectores saben qué acciones se automatizaron y cuáles requirieron intervención de analistas.

Si Google demuestra una remediación más rápida sin aumentar las interrupciones ni los incidentes no detectados, su argumento de plataforma se fortalece. Si los clientes informan de una configuración intensiva y una correlación manual persistente, el cuello de botella de la velocidad humana permanece.

La segunda señal es la respuesta de las plataformas de seguridad competidoras. Microsoft, AWS, Palo Alto Networks, CrowdStrike y otros seguirán conectando el razonamiento de IA con la detección y la respuesta.

La cuestión importante no es qué proveedor añade otro asistente. Es qué plataforma puede coordinar pruebas y acciones entre identidades, código, recursos en la nube, endpoints y aplicaciones empresariales.

La integración abierta será importante. Los clientes necesitan formas de intercambiar hallazgos, preservar pruebas y controlar acciones a través de los límites entre proveedores.

Si las plataformas competidoras publican enfoques interoperables, las empresas obtienen más libertad para ensamblar una arquitectura de defensa. Si cada proveedor construye una capa de agentes cerrada, la fragmentación de la automatización se convierte en un riesgo mayor.

Las adquisiciones y asociaciones también pueden cambiar la competencia. La combinación de Wiz, Mandiant y Gemini de Google muestra con qué rapidez un proveedor de nube puede reunir una amplia cartera de seguridad.

La tercera señal es una orientación de gobernanza más sólida por parte de reguladores y organismos de estándares. NIST está desarrollando su Cyber AI Profile, mientras que los requisitos de divulgación existentes ya obligan a los consejos a explicar la supervisión cibernética.

La futura orientación debería aclarar las expectativas para los agentes de seguridad autónomos. Las organizaciones necesitan formas comunes de documentar autoridad, pruebas, registros de auditoría, revisión humana y responsabilidad por incidentes.

Esa orientación puede fortalecer o debilitar el argumento de Google ante los consejos. Requisitos claros de supervisión continua y respuesta basada en pruebas favorecerían a las plataformas integradas.

Las normas que exijan una separación estricta, verificación independiente o una responsabilidad detallada sobre los modelos podrían ralentizar la delegación amplia a agentes gestionados por proveedores. No eliminarían la automatización, pero podrían limitar su autoridad.

Los consejos deberían utilizar estas señales para poner a prueba la estrategia de la dirección en lugar de esperar estándares definitivos. La tarea inmediata es identificar dónde los procesos a velocidad humana crean una exposición material.

Esta revisión debería comenzar por la identidad, la aplicación de parches, las dependencias de software y la preparación forense. Estas áreas aparecen repetidamente en las pruebas de incidentes, independientemente de que un atacante utilice IA avanzada.

Los directores deberían solicitar un conjunto reducido de medidas vinculadas al negocio. El tiempo para eliminar una exposición crítica, el tiempo para contener el compromiso de una identidad privilegiada y la capacidad de recuperar servicios esenciales son más útiles que los totales brutos de alertas.

También deberían solicitar un inventario de la automatización de seguridad. El inventario debería mostrar el responsable de cada agente, los datos accesibles, las acciones permitidas, los umbrales de aprobación y el proceso de apagado de emergencia.

La cobertura informativa sobre Google seguirá centrándose en ataques y defensas cada vez más autónomos. Los consejos deberían centrarse en si sus organizaciones pueden explicar y controlar la automatización que ya existe dentro de sus entornos.

La acción inmediata es una revisión conjunta que involucre a seguridad, ingeniería, legal, riesgos y operaciones empresariales. Pregunten qué decisiones de respuesta todavía dependen de una coordinación manual lenta y determinen cuáles pueden automatizarse de forma segura.

Google Cloud tiene razón al afirmar que los ciclos anuales de revisión son demasiado lentos para las amenazas a velocidad de máquina. La pregunta sin responder es si su plataforma puede ofrecer una defensa más rápida sin crear una concentración opaca de autoridad. Esa es la prueba que los directores deberían exigir a continuación.