Google Gemma 4 obliga a las empresas a repensar el control de la IA en dispositivos locales

Google Gemma 4 ha complicado la vida a los equipos de seguridad corporativa: los modelos de pesos abiertos ya pueden ejecutarse directamente en los portátiles de los empleados, sin pasar por pasarelas en la nube ni por los puntos de control habituales. Para los CISO no es simplemente otro modelo, sino un cambio en la propia arquitectura del riesgo: la inferencia y los escenarios con agentes se trasladan a los dispositivos finales.

El perímetro ya no basta

Durante los últimos dos años, muchas empresas construyeron su defensa sobre una premisa sencilla: si los empleados usan LLM externos, todo el tráfico puede canalizarse a través de pasarelas corporativas, CASB y sistemas de registro. Ese enfoque funcionó mientras la IA generativa vivía sobre todo en la nube.

El lanzamiento de Google Gemma 4 cambia ese esquema. El modelo de pesos abiertos, con licencia Apache 2.0, se puede descargar, desplegar en local y convertir un portátil de trabajo corriente en un nodo de cálculo autónomo, que no necesita comunicarse constantemente con infraestructura externa.

Google ha reforzado este cambio no solo con el modelo, sino con herramientas complementarias como Google AI Edge Gallery y la biblioteca LiteRT-LM. Facilitan la ejecución local, aceleran la inferencia y ayudan a construir escenarios con agentes más estructurados. Como resultado, un agente local puede leer instrucciones, planificar varios pasos seguidos y ejecutar tareas en el dispositivo sin la huella de red habitual. Para el equipo de seguridad es un escenario doloroso: si las solicitudes no salen al exterior, el perímetro de red simplemente no ve qué ocurre.

«¿Qué se está ejecutando exactamente ahora en los dispositivos

finales?» es la pregunta que los CISO tendrán ahora que afrontar inevitablemente.

Auditoría y cumplimiento

El principal problema de la inferencia local no es que los datos salgan necesariamente de la empresa, sino que desaparece la observabilidad. Cuando un ingeniero procesa un documento sensible con un agente local, el panel central de seguridad puede no recibir ninguna señal. No hay petición a una API externa, ni registro en un log en la nube, ni una cadena de eventos clara para una investigación posterior. Es especialmente peligroso en entornos donde importa no solo proteger los datos, sino poder demostrar cómo funcionó exactamente el sistema.

• Puede que no aparezca tráfico de red si el modelo funciona sin conexión
• Los registros centralizados no recogen los pasos del agente en el dispositivo
• Un agente local puede leer archivos, acceder a bases de datos y ejecutar comandos
• Los errores, las fugas y las alucinaciones son más difíciles de investigar a posteriori

El golpe es más fuerte para bancos, aseguradoras y sanidad. Las entidades financieras ya han invertido millones en controlar las llamadas API a modelos generativos para cumplir los requisitos de los reguladores. Pero si una estrategia de trading, un scoring de riesgo interno o datos de clientes los procesa un agente local sin registro, la empresa pierde a la vez visibilidad técnica y perímetro de cumplimiento. En sanidad la situación es parecida: aunque los datos del paciente no salgan físicamente del portátil, la falta de una auditoría verificable socava los requisitos básicos para tratar información médica.

Control en lugar de prohibiciones

La reacción instintiva de la dirección en estos casos es añadir más aprobaciones, comités de revisión y políticas prohibitivas. Pero el autor del artículo lo llama una trampa de gestión: la burocracia rara vez frena a un desarrollador con una fecha límite encima. Mucho más a menudo empuja los experimentos a la sombra, donde surge una nueva capa de TI en la sombra, esta vez no en torno a servicios SaaS, sino a agentes locales autónomos. Formalmente el control aumenta; en la práctica la empresa pierde lo que le quedaba de transparencia y acaba con un entorno aún menos gestionable.

Por eso el foco pasa de prohibir el modelo a controlar la intención y el acceso. Incluso un agente Gemma 4 ejecutado en local choca con los permisos del sistema: acceso a archivos, bases de datos corporativas, repositorios internos y comandos de shell. Esa capa debe convertirse en el nuevo perímetro digital. Los CTO y CISO tendrán que desplegar herramientas de endpoint capaces de detectar inferencia local anómala, vigilar la carga no autorizada de la GPU y distinguir el trabajo normal de un desarrollador de un agente autónomo que recorre masivamente la estructura de archivos para cumplir un prompt.

Qué significa

Se acaba la época en que la IA corporativa solo podía controlarse mediante pasarelas en la nube. Google Gemma 4 muestra que los modelos con agentes potentes se trasladan rápidamente a los dispositivos de los empleados, y con ello cambia toda la lógica de la seguridad. Ganarán las empresas que aprendan a ver no solo el tráfico de red, sino el comportamiento real de los sistemas de IA locales en los endpoints.