Z.ai desactivó funciones de su asistente de programación tras denuncias de repositorios completos enviados a servidores extranjeros sin consentimiento. Mientras OpenAI pide estándares globales para la IA avanzada, el incidente revela una verdad incómoda: el mayor riesgo no está en el modelo, sino en los permisos, la telemetría y la confianza ciega.
Escucha el artículo

Si tu asistente de IA puede leer todo tu repositorio, también puede llevárselo entero. Y eso no es una hipótesis paranoica: acaba de ocurrir. Z.ai desactivó funciones de su asistente de programación ZCode después de que usuarios denunciaran que repositorios locales completos estaban siendo enviados a servidores extranjeros sin consentimiento.
La industria lleva meses vendiendo agentes de código como compañeros incansables. Pero un compañero no debería copiar tus secretos, tus credenciales y la lógica de tu negocio mientras tú crees que solo está completando una función. El incidente de Z.ai convierte una preocupación abstracta en una pregunta brutalmente práctica: ¿quién controla realmente el código cuando instalas un asistente de IA?
Reuters informó el 21 de septiembre que la startup china Z.ai desactivó parte de las funciones de su producto estrella después de las denuncias. Según la información republicada por medios como MarketScreener y TradingView, algunos usuarios observaron que el sistema subía repositorios locales completos a infraestructura cloud ubicada fuera del país, sin una autorización clara.
El origen señalado fue la función “Codebase Indexing” de ZCode. Estaba habilitada por defecto y su objetivo parecía razonable: indexar el proyecto para ofrecer respuestas más relevantes, entender dependencias y navegar una base de código grande. Z.ai afirmó que parcheó la vulnerabilidad y desactivó temporalmente funciones mientras investigaba.
Aquí está el detalle que no debe pasar desapercibido: indexar código no es una tarea inocua. Para comprender un proyecto, una herramienta puede leer archivos de configuración, variables de entorno mal protegidas, claves de API, documentación interna, contratos, algoritmos propietarios y comentarios que jamás debieron salir del equipo.
El problema no exige que la empresa tenga intención de espiar. Basta una decisión de producto opaca, una configuración activada por defecto o una ruta de almacenamiento mal diseñada. En seguridad, el resultado importa más que el eslogan.
Apple ofrece un contraste útil desde otro frente. La compañía pidió esta semana a los desarrolladores preparar sus aplicaciones para nuevos dispositivos, SDK y formatos de pantalla con Xcode 27.1 y 27.2. Es el trabajo normal del desarrollo moderno: las herramientas obtienen cada vez más contexto para adaptarse. La diferencia es que el contexto de una interfaz puede ser público; el contexto completo de un repositorio suele ser el activo más sensible de una empresa.
Los equipos tratan los asistentes de programación como si fueran editores de texto más listos. Técnicamente, se parecen mucho más a integraciones privilegiadas. Pueden recorrer directorios, ejecutar comandos, instalar dependencias, consultar Git, abrir conexiones y, en algunos casos, usar credenciales presentes en la sesión.
Esa combinación cambia el modelo de amenaza. Un autocompletado defectuoso introduce un bug que quizá detecte una prueba. Un agente con permisos excesivos puede extraer información antes de que exista un diff para revisar.
El código generado se puede auditar; el código exfiltrado ya no se puede recuperar.
Por eso el consentimiento no puede reducirse a una casilla enterrada en los términos de servicio. Un desarrollador necesita saber qué archivos se leen, cuáles se envían, a qué región, durante cuánto tiempo se almacenan, si se usan para entrenamiento y cómo se borran. También necesita controles para excluir rutas sensibles y verificar que esas exclusiones se cumplen.
El modo por defecto importa. Cuando el indexado total viene activado de fábrica, la herramienta traslada el riesgo al usuario sin obligarlo a tomar una decisión consciente. Es el mismo patrón que vimos durante años con telemetría, cookies y sincronización automática, pero aplicado ahora a propiedad intelectual que puede valer millones.
La amenaza crece con los plugins y los agentes. Una extensión comprometida, una actualización maliciosa o una instrucción escondida en un archivo pueden convertir el acceso legítimo en una cadena de acciones no deseadas. Ya no basta con revisar quién fabricó el modelo. También hay que revisar el cliente, sus dependencias, sus conectores y su política de red.
Mientras Z.ai apagaba funciones por un incidente concreto, OpenAI pidió que Estados Unidos lidere un esfuerzo internacional para definir estándares técnicos globales de IA avanzada. Reuters señala que la propuesta incluye sistemas capaces de mejora recursiva: modelos que pueden ampliar de forma autónoma sus propias capacidades.
Pedir estándares es sensato. La interoperabilidad, las evaluaciones de seguridad y los mecanismos comunes de reporte pueden elevar el suelo mínimo de la industria. Pero también existe un conflicto evidente: las compañías con más capital, cómputo y acceso político son las mejor posicionadas para convertir sus prácticas en estándar.
Una regulación escrita únicamente alrededor de modelos “frontera” corre el riesgo de ignorar el daño cotidiano. El repositorio que sale de un portátil sin permiso no necesita una superinteligencia ni mejora recursiva. Necesita una extensión con demasiado acceso y controles deficientes.
Ahí aparece la oportunidad que muchos están pasando por alto. Los estándares realmente útiles deberían empezar más abajo: permisos declarativos, procesamiento local verificable, registros de transferencia, residencia de datos, exclusiones por defecto, credenciales temporales y alertas visibles cuando una herramienta intenta enviar archivos.
Ese enfoque no frena la innovación. La hace vendible a empresas serias. Un agente que puede demostrar dónde procesa el código y qué acciones ejecutó vale más que otro ligeramente mejor en benchmarks pero imposible de auditar.
Para desarrolladores freelance, startups y equipos pequeños, la primera medida es separar comodidad de necesidad. Si una herramienta solo debe sugerir código para el archivo abierto, no necesita acceso a todo el monorepo. Si debe ejecutar pruebas, no necesita credenciales de producción.
Antes de instalar un asistente de IA, conviene revisar cinco puntos:
Después viene la arquitectura. Los agentes deben trabajar en ramas aisladas, contenedores o entornos desechables. Las claves deben ser temporales y tener permisos mínimos. Los archivos .env, certificados, volcados de bases de datos y carpetas de infraestructura sensible no deberían formar parte del contexto salvo una razón explícita.
También hay que vigilar la red. Una política de salida limitada puede impedir que una herramienta envíe información a destinos inesperados. En equipos profesionales, el proxy, el DNS y los logs de endpoint dejan de ser obsesiones del departamento de seguridad: son la única forma de verificar lo que una herramienta promete.
Finalmente, no confundas reputación con garantía. Z.ai corrigió y desactivó funciones, que es mejor que esconder el problema, pero la lección aplica a todos los proveedores. Los nombres grandes también cometen errores. La confianza debe construirse con controles comprobables, no con logos conocidos.
La próxima guerra de los asistentes de programación no se ganará por quién escribe la función más rápido. Se ganará por quién puede trabajar con contexto suficiente sin apropiarse de él, demostrar cada transferencia y fallar dentro de límites seguros.
Si quieres integrar asistentes o agentes de IA sin exponer el código que sostiene tu negocio, hablemos. Soy Brayan, desarrollador freelance, y puedo ayudarte a diseñar un flujo de automatización útil, auditable y con permisos que tengan sentido.