Hace poco tuve la oportunidad de sentarme a charlar con Francis de Souza, director de operaciones de Google Cloud, entre bambalinas de un evento en Los Ángeles. En medio del jaleo habitual de estas ferias, de Souza, con esa calma tan suya que recuerda a un profesor universitario, soltó un par de verdades incómodas sobre este momento de locura que estamos viviendo con la seguridad en la inteligencia artificial. Dice que estamos en una “fase de transición” y que acabaremos llegando a un lugar mejor. Pero, claro, salta a la vista que hasta la propia Google sigue intentando aclararse sobre la marcha.
El núcleo del mensaje de de Souza es el mismo que los expertos en ciberseguridad llevan años intentando meter en la cabeza de los directivos, solo que ahora la IA le ha puesto el turbo. Nada de dejar la seguridad para el final. Cuando las empresas se meten en el barro de la IA, tienen que pensar en un enfoque de plataforma. No vale con ponerle un parche a posteriori ni dejar que los empleados se busquen la vida. Habló sin tapujos sobre el peligro de la IA en la sombra (shadow AI) —esa costumbre de la plantilla de tirar de herramientas comerciales sin que nadie lo supervise— y dejó claro que hay que exigir gobernanza y auditoría desde el minuto cero. Una estrategia de IA sin una buena estrategia de datos y seguridad es, directamente, papel mojado. Van de la mano.
Y ojo, que no estaba soltando el típico panfleto comercial de Google Cloud. De hecho, cuando le dejé caer que sonaba un poco a anuncio de su negociado, se defendió rápido. Google apuesta por un entorno multinube, y argumenta que quien crea que está operando en una sola nube seguramente se equivoque. Siempre hay alguna aplicación SaaS de por medio o socios usando otros entornos. Por eso toca tener una postura de seguridad que no haga aguas al saltar entre distintas plataformas o modelos.
El panorama de amenazas ha cambiado tanto que las defensas de toda la vida se han quedado a pedales. El tiempo medio entre una brecha inicial y la siguiente fase de un ataque ha caído en picado: de ocho horas a apenas 22 segundos. Y la superficie de ataque ya no es solo el perímetro tradicional de la red. Ahora tienes modelos, tuberías de datos (pipelines) para entrenarlos, agentes, prompts… Todo eso hay que blindarlo.
Hay un peligro bastante curioso que de Souza puso sobre la mesa y del que casi no se habla: los agentes autónomos que trastean por los sistemas internos pueden sacar a la luz repositorios de datos que llevaban años criando polvo. Piensa en esos servidores viejos de SharePoint que nadie se ha molestado en actualizar porque, total, nadie se acordaba de que existían. Sueltas a un agente por la red corporativa y te destapa todas esas vergüenzas al instante al exponer los datos.
¿Su solución? Combatir la velocidad de las máquinas con más máquinas. Habla de defensas nativas de IA basadas en agentes, donde los humanos pasen a ser meros supervisores de una defensa totalmente automatizada. Esto ya no es un marrón para el departamento de TI, es un tema que tiene que escalarse a la junta directiva y al equipo ejecutivo. El problema es que, mientras la IA asume más carga de trabajo, nos faltan manos cualificadas para controlarla. Las vulnerabilidades se multiplican como setas y la industria apenas da abasto. Lea Kissner, CISO de LinkedIn, lo bautizó esta semana en The New York Times como un “apocalipsis de bugs”, vaticinando que vamos a tardar unos cuantos años en entender de verdad cómo asegurar la IA a largo plazo de forma sostenible.
Y aquí es donde la teoría choca de bruces con la realidad, devolviéndonos a los propios proveedores de plataformas. Por mucho que Google aleccione sobre el control de costes y la seguridad de los agentes, The Register lleva semanas destapando una oleada de desarrolladores de Google Cloud que se han comido facturas de cinco cifras por llamadas no autorizadas a la API de Gemini. Servicios que la mayoría ni siquiera había usado o activado a propósito.
La jugada sigue un patrón frustrante: claves de API que en su día se crearon para Google Maps, expuestas públicamente siguiendo las propias instrucciones de Google, de repente servían para acceder a Gemini. ¿El motivo? Alguien en la compañía decidió ampliar el alcance de esas claves sin avisar claramente del cambio. Rod Danan, CEO de la plataforma Prentus, vio cómo su factura se disparaba a 10.138 dólares en apenas media hora después de que unos atacantes explotaran su clave. A Isuru Fonseka, un desarrollador de Sídney, le colaron unos 17.000 dólares australianos mientras dormía, y eso que juraba tener un límite de gasto estricto de 250 dólares. Lo que ninguno sabía es que los sistemas automatizados de Google les habían subido el nivel de facturación basándose en su historial de cuentas, elevando el techo de gasto efectivo hasta los 100.000 dólares sin su consentimiento explícito. Un despropósito que ilustra a la perfección el caos de gobernanza del que hablábamos.
Quizá para atajar problemas de este calibre y dar a los programadores herramientas tangibles para construir esas defensas robustas, Google acaba de mover ficha a nivel de código. Han introducido una arquitectura de Middleware para Genkit, su framework de código abierto para montar aplicaciones impulsadas por IA.
Básicamente, le han metido una capa de intercepción programable que envuelve las llamadas al modelo, la ejecución de herramientas y los bucles de generación. La idea es dar a los desarrolladores la sartén por el mango en temas de fiabilidad y seguridad dentro de los sistemas en producción. Ahora pueden inyectar comportamientos a medida —como reintentos, alternativas a otros modelos en caso de fallo (fallbacks) o registros de actividad— sin tener que tocar la lógica central de la aplicación. De momento tira de forma nativa con TypeScript, Go y Dart, con el soporte para Python calentando en la banda.
A nivel operativo, cada vez que se llama a la función generate() en Genkit, el modelo produce un resultado, ejecuta herramientas, procesa los datos y sigue hasta terminar. Con este middleware, puedes meter mano en ese ciclo en tres niveles clave: la propia generación, las llamadas al modelo y la ejecución de las herramientas. Incluso han sacado componentes ya masticados para facilitarte la vida: sistemas de reintento con retroceso exponencial, barreras de aprobación para herramientas sensibles, controles de acceso al sistema de archivos y un sistema de “habilidades” que inyecta instrucciones desde archivos locales. Todo esto se puede apilar en cadena, permitiendo que filtros, aprobaciones y registros se ejecuten en un orden definido, y monitorizarlo desde la interfaz de Genkit para depurar los fallos en caliente.
Este movimiento refleja hacia dónde va todo el ecosistema de herramientas IA. Ya no basta con afinar los prompts o reentrenar modelos; los frameworks necesitan capas de código que aten en corto a los agentes mientras operan. Como era de esperar, esto ha traído cola en redes como X, donde los desarrolladores debatían cómo encaja Genkit frente al Agent Development Kit (ADK) de la propia compañía. Michael Doyle, ingeniero de Google, lo zanjó rápido: si tienes una app web o móvil y quieres meterle funciones de agente, usas Genkit. Si estás montando sistemas multiagente complejos e independientes corriendo directamente sobre la plataforma de agentes de Google Cloud Platform (GCP), te vas a ADK.
