Por Canuto  

Google Cloud sostiene que la seguridad debe ir de la mano con toda estrategia de IA, pero una serie de incidentes recientes con claves expuestas, cargos de cinco cifras y revocaciones lentas en Gemini muestra que incluso los grandes proveedores aún están resolviendo riesgos críticos en tiempo real.
***

  • Francis de Souza, COO de Google Cloud, advirtió que no existe estrategia de IA sin estrategia de datos y seguridad.
  • Desarrolladores afectados reportaron facturas de hasta USD $10.138 en 30 minutos y cargos cercanos a AUD $17.000 tras accesos no autorizados a Gemini.
  • Una investigación de Aikido concluyó que algunas claves de API eliminadas podían seguir funcionando hasta 23 minutos dentro de la infraestructura de Google.

La expansión de la inteligencia artificial dentro de empresas y plataformas en la nube está reconfigurando la ciberseguridad a una velocidad poco habitual. Lo que antes se trataba como una capa adicional de protección ahora se presenta como una condición básica de diseño, especialmente cuando modelos, agentes, prompts y canalizaciones de datos pasan a integrarse en operaciones sensibles.

En ese contexto, Francis de Souza, COO de Google Cloud, sostuvo durante una conversación en un evento en Los Ángeles que la seguridad no puede tratarse como una ocurrencia tardía. Su planteamiento fue que las organizaciones que avanzan en IA deben hacerlo desde una lógica de plataforma, con controles de gobernanza, auditoría y protección definidos desde el inicio.

Sin embargo, el mensaje llega en un momento incómodo para Google. Mientras la compañía insiste en que las empresas deben elevar sus estándares de seguridad ante la IA, varios reportes recientes han mostrado que algunos servicios vinculados a Gemini todavía presentan fricciones importantes en revocación de credenciales, exposición de claves y control de gasto.

La tensión entre el discurso y la ejecución resulta relevante para cualquier empresa que dependa de grandes proveedores cloud. En la práctica, la discusión ya no gira solo en torno a la potencia de los modelos, sino a la velocidad con la que una falla puede traducirse en pérdidas operativas, exposición de datos o facturación inesperada.

Google Cloud pide una estrategia integral de seguridad para la IA

De Souza defendió que no existe una estrategia de IA sin una estrategia de datos y una estrategia de seguridad. Según explicó, ambas deben avanzar juntas. También advirtió sobre la llamada “IA en la sombra”, es decir, el uso de herramientas de consumo por parte de empleados sin supervisión formal de la organización.

Su advertencia apunta a un problema conocido en tecnología empresarial: cuando el acceso a nuevas herramientas se acelera, los equipos de seguridad suelen reaccionar después. En el caso de la IA, ese retraso puede ser más costoso porque los sistemas no solo procesan datos, sino que también interactúan con múltiples entornos internos y externos.

El ejecutivo insistió en que las compañías deben exigir seguridad, gobernanza y auditabilidad desde el principio. También rechazó que su mensaje fuera una simple promoción de Google Cloud. Afirmó que la realidad empresarial es multicloud, incluso para organizaciones que creen operar en una sola nube.

Según su visión, una empresa puede depender de una sola infraestructura principal y aun así estar expuesta a servicios SaaS, proveedores externos y socios comerciales que operan sobre otras nubes. Por eso, dijo, la postura de seguridad debe mantenerse consistente entre nubes y entre modelos.

Ese enfoque tiene implicaciones directas para sectores financieros, exchanges, fintechs y firmas de análisis de datos, donde la fragmentación tecnológica es habitual. A medida que la IA se integra en atención al cliente, compliance, monitoreo de fraude y automatización interna, el riesgo también se distribuye entre más puntos de acceso.

Una superficie de ataque más amplia y mucho más rápida

De Souza sostuvo que el panorama de amenazas cambió de forma estructural. Señaló que el tiempo promedio entre una brecha inicial y el paso a la siguiente etapa de un ataque cayó de ocho horas a 22 segundos. Esa cifra resume por qué los modelos defensivos tradicionales empiezan a parecer insuficientes.

En su explicación, la superficie de ataque ya no se limita al perímetro clásico de red. Ahora incluye modelos, datasets de entrenamiento, canalizaciones de datos, agentes y prompts. Cada uno de esos componentes puede convertirse en un punto vulnerable si no existe una arquitectura de seguridad clara y supervisada.

Entre los riesgos que, a su juicio, reciben menos atención está el comportamiento de agentes capaces de recorrer sistemas internos de una empresa. De Souza advirtió que esos agentes pueden descubrir repositorios antiguos o mal gestionados que nadie revisa desde hace años, como viejos servidores de SharePoint o activos con permisos desactualizados.

Ese escenario es particularmente delicado porque combina automatización con memoria institucional incompleta. Un activo olvidado que antes era difícil de localizar puede quedar súbitamente expuesto si un agente de IA logra hallarlo, indexarlo o conectarlo con flujos de trabajo modernos.

Para responder a esa velocidad, el ejecutivo defendió una defensa nativa de IA y completamente agéntica. En lugar de una seguridad conducida por humanos o con un humano en el bucle, propuso sistemas donde agentes automatizados ejecuten la defensa y las personas cumplan una función de supervisión.

También sostuvo que el problema ya escaló al nivel del consejo de administración y del equipo ejecutivo. En otras palabras, dejó de ser un asunto exclusivo del equipo técnico de seguridad. Esa lectura coincide con la creciente presión regulatoria y reputacional sobre compañías que despliegan IA a gran escala.

Escasez de talento y una “bug-pocalypse” en desarrollo

El optimismo sobre la automatización defensiva convive con un problema de fondo: la industria aún no cuenta con suficientes profesionales preparados para supervisar sistemas de seguridad impulsados por IA. Al mismo tiempo, las nuevas vulnerabilidades asociadas a estos despliegues están creciendo con rapidez.

En declaraciones citadas por el New York Times, Lea Kissner, chief information security officer de LinkedIn, dijo que serán necesarias personas para lidiar con una “bug-pocalypse”. Añadió que no espera que la industria comprenda la seguridad de la IA de una manera sostenible a largo plazo al menos durante varios años.

Ese comentario ayuda a poner en perspectiva el momento actual. La seguridad de la IA no es todavía una disciplina madura con reglas estables y procesos ampliamente estandarizados. Más bien, se trata de un terreno en formación donde incluso los actores con más recursos siguen ajustando prioridades.

Para los mercados tecnológicos, esto importa más allá del plano técnico. Cuando una falla de diseño en una API, una mala revocación de credenciales o una ampliación automática de límites de gasto golpea a desarrolladores o startups, el problema puede escalar a costos financieros, pérdida de confianza y presión competitiva.

Los incidentes con Gemini exponen una brecha entre la teoría y la práctica

Esa brecha se hizo visible en una serie de reportes publicados por The Register sobre desarrolladores de Google Cloud afectados por facturas de cinco cifras tras llamadas no autorizadas a APIs de modelos Gemini. Según esos reportes, muchos de los afectados no habían usado ni habilitado intencionalmente esos servicios.

Los casos seguían un patrón similar. Claves de API implementadas originalmente para Google Maps y expuestas públicamente conforme a las propias instrucciones de Google habrían pasado a tener capacidad para acceder a Gemini después de que la empresa ampliara su alcance sin comunicar con claridad el cambio.

Rod Danan, CEO de la plataforma de preparación para entrevistas Prentus, dijo que su factura llegó a USD $10.138 en aproximadamente 30 minutos luego de que atacantes explotaran su clave de API comprometida. El caso ilustra el impacto inmediato que puede generar una credencial expuesta en servicios de alto consumo computacional.

Otro caso citado fue el de Isuru Fonseka, un desarrollador con sede en Sídney. Según el reporte, despertó con cargos cercanos a AUD $17.000 pese a creer que tenía configurado un límite de gasto de AUD $250. Lo que no sabía era que los sistemas automatizados de Google habían elevado su nivel de facturación según el historial de la cuenta.

Ese ajuste incrementó sus límites efectivos hasta USD $100.000 sin consentimiento explícito. Google reembolsó tanto a Danan como a Fonseka después de la publicación inicial del caso, pero la compañía también dijo que no planea cambiar su política de mejora automática de nivel.

De acuerdo con lo señalado a The Register, la empresa prioriza evitar interrupciones del servicio por encima de hacer cumplir las preferencias de presupuesto declaradas por los usuarios. Esa decisión toca una fibra sensible en el ecosistema desarrollador, donde los controles de gasto se consideran una barrera esencial frente a errores, abusos o compromisos de seguridad.

Revocación lenta de claves y una ventana de hasta 23 minutos

La controversia no terminó ahí. Esta misma semana, The Register informó sobre una investigación de la firma de seguridad Aikido que concluye que incluso los desarrolladores que detectan una clave comprometida y la eliminan de inmediato pueden seguir expuestos durante un periodo significativo.

Según los hallazgos de Aikido, los atacantes aparentemente pueden continuar usando esa clave hasta por 23 minutos porque la revocación se propaga de forma gradual a través de la infraestructura de Google. Durante esa ventana, la tasa de éxito no sería constante, pero sí lo bastante alta como para mantener el riesgo operativo.

Joseph Leon, investigador de Aikido, indicó que en algunos minutos más del 90% de las solicitudes seguían autenticándose. Añadió que los atacantes pueden aprovechar ese lapso para extraer archivos y datos de conversaciones en caché de Gemini, lo que amplía el problema desde la facturación hacia la posible exfiltración de información.

Leon también observó que formatos de credenciales más nuevos del propio Google no parecen tener la misma falla. Las credenciales de API de cuentas de servicio se revocan en cerca de cinco segundos, mientras que el formato más nuevo de clave de Gemini con prefijo AQ tarda aproximadamente un minuto.

Su conclusión fue directa: ambos mecanismos funcionan a escala de Google, por lo que la ventana de 23 minutos no parecería responder a un límite técnico inevitable. En su lectura, se trata más bien de una cuestión de prioridades internas sobre qué sistemas reciben antes las mejoras de seguridad disponibles.

En conjunto, el episodio deja una conclusión incómoda para todo el sector. De Souza no parece equivocado al exigir una estrategia sólida de datos, gobernanza y seguridad para la IA. Pero los hechos recientes sugieren que incluso las plataformas que emiten esa recomendación todavía están adaptándose a la velocidad y complejidad de los riesgos que ellas mismas ayudan a crear.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados