El fichero que nadie llegó a abrir

El investigador plantó un señuelo. Un único fichero, alojado en un repositorio de pruebas, que al asistente nunca se le pidió abrir y que jamás citó: un canario. Después puso el tráfico bajo un proxy y observó qué enviaba de verdad Grok Build, el CLI de programación de xAI. El canario reapareció en el paquete interceptado. Había salido de la máquina sin que nadie lo leyera.

El análisis del tráfico publicado sobre la versión 0.2.93 describe dos canales distintos. El primero es el que cualquiera espera de un asistente de código en la nube: un canal de conversación con el modelo que transporta los ficheros que el agente lee de verdad, para poder responder. El segundo es un canal de almacenamiento en segundo plano que envía una instantánea de todo el espacio de trabajo a un bucket, haya mirado el agente esos ficheros o no.

La diferencia entre ambos es el hallazgo. En un repositorio de pruebas de 12 gigabytes, el canal del modelo movió unos 192 kilobytes. El canal en segundo plano movió 5,10 gibibytes, en 73 fragmentos de unos 75 megabytes cada uno. Una diferencia de unas 27.800 veces. Un canal hacía el trabajo. El otro copiaba el edificio.

Entre los ficheros que salieron había un .env versionado, justo la convención que los desarrolladores usan para guardar lo que jamás debe viajar: claves de API, contraseñas de bases de datos. Salió literal, sin ocultar un solo carácter.

El interruptor de la pantalla no era el del cable

Toda herramienta de desarrollo con IA incluye hoy una casilla que dice, en una versión u otra, "ayúdanos a mejorar el modelo". Es el control por el que pregunta el área de compras, el que el delegado de protección de datos escribe en su evaluación y el que señala un responsable de ingeniería cuando alguien pregunta si el código está seguro.

El investigador la desactivó. Luego fue a ver qué opinaba el servidor. El endpoint de ajustes seguía devolviendo trace_upload_enabled como true. Las subidas continuaron.

Conviene separar esta parte del titular. El defecto no es que un asistente de código envíe código a un servidor: esa es la premisa entera de un asistente en la nube, y por eso uno lee las condiciones antes de instalarlo. El defecto es que el control del consentimiento y la ruta de los datos nunca estuvieron conectados entre sí. La casilla gobernaba el entrenamiento. La subida iba por otra tubería, y nada de lo que había en la pantalla llegaba hasta ella.

Un control que no controla nada es peor que no tener ninguno, porque el equipo que lo ve deja de mirar.

El hallazgo real es el arreglo en el servidor

El 13 de julio de 2026 las subidas se detuvieron. Lo instructivo es cómo. No hubo versión nueva del cliente, ni cambio de número, ni una línea en el registro de cambios que los usuarios pudieran revisar y aprobar. El mismo binario 0.2.93 simplemente dejó de hacer peticiones de almacenamiento, porque el servidor empezó a responder con un indicador nuevo que desactivaba la subida del código. Elon Musk dijo que los datos ya subidos serían, en sus palabras, "completa y absolutamente eliminados".

Vuelva a leer esa secuencia desde la óptica del gobierno del dato. El comportamiento del software instalado en los portátiles de sus desarrolladores cambió en remoto, de la mano del proveedor, sin tocar el artefacto que usted aprobó. Lo que quiere decir que podría haber cambiado en sentido contrario por la misma vía, y desde su lado habría tenido exactamente el mismo aspecto.

Esa es la lección estructural, y va mucho más allá de xAI. Si el comportamiento de una herramienta con los datos depende de indicadores del servidor, revisar el cliente una vez le dice lo que hacía el día en que lo miró. No le dice lo que hace ahora. Fijar una versión, leer las notas de publicación y dar el visto bueno es un proceso pensado para software que lleva su comportamiento dentro del binario. La mayoría del utillaje de IA ya no lo hace.

xAI no ha publicado por qué existían esas subidas, cuánto tiempo se conservaron los datos, quién podía acceder a ellos ni a cuántos usuarios afectó. Esas cuatro respuestas son las que un cliente necesita para dimensionar el incidente, y su ausencia ya es información.

Lo que un equipo europeo debe ahora a sus clientes

Empiece por la hipótesis cuyo error sale más barato: dé por revelado todo secreto que haya vivido en cualquier repositorio abierto con Grok Build. Rote claves de API, credenciales de bases de datos, claves de firma y tokens. Hágalo en función de qué repositorios se abrieron, no de qué ficheros cree usted que leyó el asistente, porque el hallazgo consiste precisamente en que esos dos conjuntos no coinciden.

Mire después qué más había en esos repositorios. El código fuente, por sí solo, es un problema comercial. Los datos personales, o las credenciales que llegan a sistemas que los tratan, son un problema jurídico. Según el RGPD, un proveedor de IA que trata su repositorio siguiendo sus instrucciones es un encargado del tratamiento, y una copia de ese repositorio aterrizando en un bucket de almacenamiento fuera de la finalidad pactada es una comunicación de datos que hay que evaluar. Si hay brecha de datos personales, el responsable español la notifica a la AEPD, y el plazo corre desde que usted tuvo conocimiento, no desde que el proveedor lo repare.

Las entidades esenciales e importantes bajo NIS2 deben tratarlo como un incidente de la cadena de suministro, registrarlo como tal y apoyarse en INCIBE-CERT, la referencia nacional de respuesta a incidentes para el sector privado. Porque eso es exactamente lo que es: un defecto en el producto de un proveedor que movió sus datos a un sitio que usted no eligió.

Nada de esto exige certeza sobre lo que xAI hizo con los datos. Solo exige que hoy usted no pueda demostrar que aquello dio igual.

Cómo comprar una herramienta de código con IA tras esto

El cambio útil no es prohibir. Los equipos que vetan de plano los asistentes de código suelen descubrir que sus desarrolladores instalaron uno igualmente, y que ya nadie lo registra. El cambio útil es dejar de tratar al cliente como la frontera.

Haga tres preguntas al proveedor antes de que la siguiente herramienta llegue a un portátil. ¿Con qué endpoints habla, y podemos verlo en nuestra propia red en lugar de en su documentación? ¿Puede su servidor cambiar lo que envía el cliente instalado sin publicar una versión nueva y, si es así, qué nos avisa de que ha ocurrido? Si un ajuste está desactivado en nuestro tenant, ¿cuál es su representación en el servidor, y nos dejarán comprobarla?

Haga luego que las respuestas sean comprobables y no contractuales. Un proxy y una tarde bastaron para producir este hallazgo. Es un control más barato que cualquier cuestionario de garantías, y el único que mide comportamiento en vez de intención. Los secretos, mientras tanto, no deberían estar en un repositorio que un agente de código pueda ver: la inyección de variables de entorno en tiempo de ejecución y un gestor de secretos administrado convierten esta clase de incidente, de brecha de seguridad, en un simple encogimiento de hombros.

Las herramientas merecen la pena. Lo que no la merece es un proceso de revisión que lee la etiqueta y nunca mira el cable.