La seguridad de la IA es un reto en tiempo real para todos, incluido Google

Hace poco tuve la oportunidad de hablar con Francis de Souza, director de operaciones de Google Cloud, entre bastidores en un evento celebrado en Los Ángeles. En medio del ruido que nos rodeaba, de Souza —que habla con el tono tranquilo y mesurado de un profesor universitario— ofreció consejos prácticos para las empresas que se enfrentan al panorama actual de la seguridad en la inteligencia artificial. Señaló: «Habrá un periodo de transición y, después, creo que llegaremos a una situación mejor».

En ese momento no se refería específicamente a Google, pero está claro que incluso Google sigue trabajando para superar estos retos.

El mensaje central de De Souza es uno que los profesionales de la seguridad llevan mucho tiempo intentando hacer entender a los ejecutivos, y que ahora la IA ha convertido en urgente: la seguridad no puede ser una cuestión secundaria. «A medida que las empresas se embarcan en este viaje hacia la IA, deben adoptar un enfoque basado en plataformas», afirmó. «La seguridad no es algo que se pueda añadir a posteriori, ni es algo que se pueda dejar en manos de los empleados para que lo hagan por su cuenta». Advirtió específicamente sobre la «IA en la sombra» —empleados que utilizan herramientas de consumo sin supervisión de la organización— y defendió que las empresas deben exigir seguridad, gobernanza y auditabilidad a sus plataformas desde el principio. «No existe una estrategia de IA sin una estrategia de datos y una estrategia de seguridad. Deben ir de la mano».

Cabe destacar que no estaba promocionando únicamente Google Cloud. Cuando le señalé que su consejo sonaba como un anuncio de Google, se defendió. Google, dijo, apuesta por un enfoque multicloud, y argumentó que las empresas que creen que operan en una única nube, es casi seguro que no lo hacen. «Incluso si eligen una única nube, dependen de aplicaciones SaaS, y hay socios comerciales que pueden estar utilizando nubes diferentes», afirmó. «Es importante que las empresas cuenten con una postura de seguridad coherente en todas las nubes y en todos los modelos».

También defendió que el panorama de amenazas ha cambiado de forma tan radical que los antiguos modelos defensivos resultan demasiado lentos. Señaló que el tiempo medio entre una brecha inicial y el paso a la siguiente fase de un ataque se ha reducido de ocho horas a 22 segundos, y que la superficie de ataque se ha expandido más allá del perímetro de red tradicional. «Además de tu infraestructura habitual, ahora tienes modelos. Tienes flujos de datos que se utilizan para entrenar los modelos. Tienes agentes, tienes indicaciones. Todo esto debe protegerse».

Una amenaza que de Souza señaló y que no recibe la atención suficiente es que los agentes que se mueven por los sistemas internos de una empresa pueden sacar a la luz repositorios de datos olvidados en los que nadie había pensado en años. «Muchas organizaciones tienen servidores SharePoint antiguos [y controles de acceso] que realmente no han actualizado, pero eso no importaba porque nadie sabía realmente dónde estaban. Sin embargo, los agentes que deambulan por tu empresa encontrarán esos activos de datos y expondrán la información que contienen».

La solución, en su opinión, es contrarrestar la velocidad de las máquinas con la velocidad de las máquinas. «Ahora estamos asistiendo al surgimiento de una defensa totalmente basada en agentes y nativa de la IA, en la que las organizaciones pueden ejecutar agentes que dirijan su defensa», afirmó. «En lugar de contar con una defensa dirigida por personas o incluso con la intervención humana en el proceso, ahora es posible que sean las personas las que supervisen una defensa totalmente basada en agentes». Añadió que esto se ha convertido en una cuestión de liderazgo, no solo tecnológica. «Se trata de un asunto que compete al consejo de administración y al equipo ejecutivo. No es solo un asunto del equipo de seguridad».

Pero, aunque la IA asuma cada vez más la carga de trabajo defensiva, escasea el personal cualificado para supervisarla, y las vulnerabilidades que la propia IA está introduciendo se multiplican más rápido de lo que los equipos de seguridad pueden abordarlas. «Vamos a necesitar personas que se ocupen del ‘bug-pocalipsis’», declaró esta semana Lea Kissner, directora de seguridad de la información de LinkedIn, al *New York Times*, y añadió que no espera que el sector comprenda la seguridad de la IA de forma sostenible a largo plazo hasta dentro de al menos varios años.

Lo cual nos lleva de vuelta a los propios proveedores de plataformas. The Register ha publicado una serie de informes en las últimas semanas en los que se documenta una oleada de desarrolladores de Google Cloud que se han visto afectados por facturas de cinco cifras tras llamadas a la API no autorizadas a modelos de Gemini —servicios que muchos de ellos nunca habían utilizado ni activado intencionadamente—. Los casos siguieron un patrón habitual: las claves de API, implementadas originalmente para Google Maps y publicadas de acuerdo con las propias instrucciones de Google, habían pasado a poder acceder a Gemini de forma silenciosa después de que Google ampliara su alcance sin comunicar claramente el cambio.

Rod Danan, director ejecutivo de la plataforma de preparación de entrevistas Prentus, afirmó que su factura ascendió a 10 138 dólares en unos 30 minutos después de que los atacantes aprovecharan su clave de API comprometida. Isuru Fonseka, un desarrollador afincado en Sídney cuya cuenta también se vio comprometida, se despertó con unos cargos de aproximadamente 17 000 dólares australianos a pesar de creer que tenía establecido un límite de gasto de 250 dólares. Lo que ninguno de los dos sabía era que los sistemas automatizados de Google habían elevado sus niveles de facturación basándose en el historial de la cuenta, aumentando sus límites máximos efectivos hasta los 100 000 dólares sin consentimiento explícito.

Google reembolsó a ambos después de que The Register publicara su informe inicial. Aun así, Google comunicó a The Register que no tiene previsto cambiar su política de aumento automático de los niveles de facturación, alegando que da prioridad a evitar interrupciones del servicio frente a hacer cumplir las preferencias presupuestarias indicadas por los usuarios.

Mientras tanto, se plantea otra cuestión: ¿qué ocurre cuando un desarrollador intenta desactivar el servicio? The Register informó esta semana sobre una investigación de la empresa de seguridad Aikido que reveló que incluso los desarrolladores que detectan una clave comprometida y la eliminan de inmediato pueden no estar a salvo. Según las conclusiones de Aikido, al parecer los atacantes pueden seguir utilizando esa clave durante un máximo de 23 minutos, ya que la revocación de Google se propaga gradualmente a través de su infraestructura. Joseph Leon, investigador de Aikido, explicó a The Register que, durante ese intervalo, las tasas de éxito son impredecibles —en algunos minutos, más del 90 % de las solicitudes siguen autenticándose— y los atacantes pueden aprovechar ese tiempo para extraer archivos y datos de conversaciones almacenados en caché de Gemini.

Leon también señaló que los formatos de credenciales más recientes de la propia Google no parecen tener el mismo problema: las credenciales de la API de las cuentas de servicio se revocan en unos cinco segundos, y el nuevo formato de clave de Gemini, con el prefijo «AQ», tarda aproximadamente un minuto. «Ambos funcionan a escala de Google», escribió en el artículo relacionado de Aikido. «Ambos sugieren que esto también tiene solución técnica para las claves de la API de Google». En resumen, según Leon, el intervalo de 23 minutos no es una limitación técnica, sino una cuestión de prioridades para la empresa.

Vale la pena tenerlo en cuenta al leer los consejos de de Souza, que son acertados y deben tomarse muy en serio. No se equivoca, pero actualmente existe una brecha entre lo que prescriben las plataformas y la rapidez con la que ellas mismas se están adaptando, y es bueno ser consciente de ello también.