Agentes de IA · 8 min de lectura

Agentes de programación y computer use: qué cambió con Terra, Carbon y Opus 5.5, y cómo usarlos sin abrirle la puerta a un ataque

Los modelos nuevos priorizan agentes que programan y operan computadoras durante horas. Qué traen GPT-6.1 Terra, Gemini 4 Carbon y Claude Opus 5.5, los riesgos reales del código generado por IA y de las plataformas de agentes, y un marco práctico para llevarlos a producción en una empresa.

Por GEDX · 3 de noviembre de 2026

Los modelos de IA de esta temporada ya no compiten solo por responder mejor: compiten por trabajar solos durante más tiempo. En las últimas seis semanas, OpenAI, Google DeepMind y Anthropic lanzaron modelos cuyo argumento principal es el mismo: agentes que programan, operan computadoras y sostienen flujos de trabajo largos con menos intervención humana. Al mismo tiempo crece la evidencia de dos riesgos: el código que generan todavía trae vulnerabilidades, y las plataformas donde corren esos agentes se volvieron un blanco.

En corto: los agentes de programación ya sirven para producción, pero solo con un perímetro claro: entorno aislado, mínimo privilegio, revisión humana en lo sensible y registros que el agente no pueda borrar.

Qué trajeron los modelos nuevos

Modelo Fecha En qué apuesta Dato clave
GPT-6.1 Terra (OpenAI) 26-oct-2026 Computer use rápido y barato para el trabajo diario: lee la pantalla, hace clic, escribe y cambia de aplicación US$1 por millón de tokens de entrada y US$5 de salida, la mitad que su predecesor. En tareas de terminal resuelve cerca de la mitad, más del doble que la versión anterior (datos de OpenAI)
Gemini 4 Carbon (Google DeepMind) 28-oct-2026 Ingeniería de largo horizonte: flujos agénticos persistentes durante días, análisis de causa raíz y ciberseguridad 59 puntos en el Coding Agent Index de Artificial Analysis. Por ahora solo para expertos en ciberseguridad y socios seleccionados
Claude Opus 5.5 (Anthropic) 22-sep-2026 Programación agéntica, computer use y trabajo de conocimiento, a menor costo 62 en el mismo Coding Agent Index. Según Anthropic, resuelve más tareas de terminal que Opus 5 con cerca de 40% menos llamadas

Tres lecturas para una empresa:

  1. El costo dejó de ser la barrera. Un modelo como Terra hace viable automatizar tareas rutinarias en pantalla (capturar facturas, llenar portales, mover datos entre sistemas) a una fracción del precio de hace un año.
  2. La especialización importa más que el ranking. Terra está optimizado para velocidad y precio; Carbon para problemas largos y difíciles; Opus 5.5 para programación agéntica. OpenAI mismo recomienda sus modelos más grandes para el código más complejo. Elegir un solo modelo para todo es pagar de más o quedarse corto.
  3. Los propios fabricantes suben la guardia en seguridad. OpenAI clasificó a Terra en el nivel «Critical» de capacidades de ciberseguridad de su marco de preparación, y Google liberó Carbon primero a defensores de ciberseguridad. Cuando un modelo puede encontrar y explotar fallas, la misma capacidad tiene que controlarse dentro de la empresa.

Las mejoras prácticas que sí cambian el día a día

Más allá de los benchmarks, lo que vuelve operables a estos agentes son funciones poco vistosas:

  • Permisos más finos. Las herramientas están pasando de «el agente puede todo o nada» a permisos por agente, por herramienta y por operación, con aprobaciones explícitas para acciones sensibles.
  • Hilos y sesiones largas. Los agentes de largo horizonte necesitan conservar contexto durante horas o días, retomar el trabajo donde quedó y dejar un historial revisable de lo que hicieron y por qué. Los SDK de agentes ya incorporan sandboxes controlados y control sobre qué memoria se crea y dónde se guarda.
  • Computer use más fiable y barato. Los costos por tarea están bajando rápido, pero la tasa de éxito en benchmarks difíciles como OSWorld 2.0 sigue lejos del 100%. Hoy funciona para procesos acotados y con verificación, no para dejar un agente solo en cualquier sistema.

Riesgo 1: el código generado por IA no es seguro por defecto

  • Cerca del 45% de las muestras de código generado por IA introdujo vulnerabilidades del OWASP Top 10 en las pruebas de Veracode, y su actualización de marzo de 2026 indica que la tasa no ha mejorado: los modelos más grandes programan mejor, pero no más seguro.
  • Las fallas que más crecen no son de sintaxis, sino de arquitectura, autorización y privilegios: justo las que un escáner basado en patrones detecta peor y las que más daño hacen.
  • Cerca del 20% de las muestras sugirió paquetes que no existen. Un atacante puede registrarlos con ese nombre y esperar a que alguien los instale (slopsquatting).

Y hay una preocupación más fina: la puerta trasera sutil. Un cambio que pasa las pruebas, se ve razonable en la revisión rápida y deja abierta una ruta de acceso: una validación que se omite en un caso límite, un permiso más amplio de lo necesario o una dependencia que no debería estar ahí. Puede venir de un error del modelo o de instrucciones maliciosas escondidas en el contexto que el agente leyó (un README, un issue, un comentario en el código). Por eso la regla no puede ser «si las pruebas pasan, se integra».

Riesgo 2: la plataforma del agente también es un objetivo

Durante 2026 se documentó una ola de fallas en las propias herramientas de programación con IA, que afectaron a prácticamente todos los nombres conocidos del mercado. Las clases de problema que más se repiten:

  • El repositorio como vector: configuraciones de git, hooks y archivos de configuración de agentes que se ejecutaban antes de que apareciera la solicitud de aprobación.
  • Actualizaciones de plugins que podían cambiarse por código malicioso.
  • Escapes del sandbox y servicios locales del agente accesibles desde una página web.
  • Inyección de instrucciones desde contenido externo: resultados de búsqueda, documentación o salidas de otras herramientas.
  • Agentes que podían borrar sus propios registros de ejecución.
  • Robo de credenciales: los infostealers ya buscan tokens de agentes y configuraciones con llaves de acceso.

Varias de estas fallas ya fueron corregidas por los fabricantes, pero el patrón es claro: un agente con acceso a su máquina, su repositorio y sus llaves es una identidad privilegiada, y debe tratarse como tal.

Cómo llevar agentes de programación a producción: el marco que usamos

  1. Entorno aislado y desechable. El agente trabaja en un contenedor o máquina temporal, nunca en la laptop con todas las llaves ni con acceso directo a producción. Los repositorios de terceros se abren solo ahí.
  2. Mínimo privilegio. Permisos por agente y por herramienta, secretos fuera del árbol del proyecto, tokens de corta vida y rotación junto con el resto de las credenciales.
  3. La configuración del repositorio se revisa como código. Hooks, archivos de configuración del agente y plugins pasan por revisión; las actualizaciones automáticas de plugins se desactivan hasta verificarlas.
  4. Cada commit se escanea. Análisis estático (SAST), dependencias contra un inventario (SBOM) y detección de secretos, con bloqueo automático del merge si algo falla.
  5. Revisión humana obligatoria en las zonas sensibles. Autenticación, autorización, criptografía, validación de entradas y acceso a datos personales los aprueba un ingeniero. El agente es excelente para el código repetitivo, las pruebas y la refactorización; el criterio sobre seguridad se queda con una persona.
  6. Registros que el agente no puede tocar. Cada acción queda en un almacenamiento externo, con trazabilidad de qué humano o sistema la originó. Hoy solo una minoría de las organizaciones puede rastrear de forma fiable las acciones de sus agentes.
  7. Multimodelo por tarea. Un modelo rápido y barato para lo rutinario, uno de largo horizonte para lo complejo y una revisión cruzada para lo crítico. Así se controla el costo y se reduce la dependencia de un solo proveedor.

Es el mismo criterio con el que llevamos IA a producción en GEDX: IA como copiloto, criterio humano al volante. El agente propone y ejecuta dentro de un perímetro; un ingeniero decide.

Qué hacer esta semana

  • Haga inventario de qué herramientas de programación con IA usa su equipo, incluidas las que nadie autorizó.
  • Revise con qué permisos corren y a qué llaves y repositorios tienen acceso.
  • Active el escaneo de secretos y dependencias en cada commit, no solo en el pipeline final.
  • Defina por escrito qué zonas del código requieren aprobación humana.

Si quiere llevar agentes de programación o de computer use a un proceso real de su empresa, con permisos, revisión y monitoreo desde el primer día, hablemos de su caso.

Fuentes

Publicado el 3 de noviembre de 2026. Las cifras de los fabricantes provienen de sus propias pruebas y se actualizarán si cambian.

Preguntas frecuentes

¿Qué es un agente de programación (coding agent)?

Es un sistema de IA que no solo sugiere código: planea una tarea, lee el repositorio, escribe y modifica archivos, ejecuta comandos y pruebas, y corrige sus propios errores durante minutos u horas. Ejemplos conocidos son Claude Code, Codex, Cursor o Gemini CLI.

¿Qué es computer use?

Es la capacidad de un modelo de IA de operar una computadora como lo haría una persona: ver la pantalla, hacer clic, escribir y moverse entre aplicaciones. Sirve para automatizar procesos en sistemas que no tienen API, como portales, ERPs antiguos o formularios web.

¿Es seguro el código que genera la IA?

No por defecto. En las pruebas de Veracode, cerca del 45% de las muestras de código generado por IA introdujo vulnerabilidades del OWASP Top 10, y esa tasa no mejoró entre 2025 y principios de 2026. El código generado necesita la misma revisión de seguridad que el escrito por personas, y una revisión humana obligatoria en autenticación, permisos, criptografía y manejo de datos.

¿Cómo se usa un agente de programación en una empresa sin aumentar el riesgo?

Con cinco controles: ejecutar el agente en un entorno aislado y desechable, darle el mínimo privilegio y nunca acceso directo a producción, revisar la configuración del repositorio como código, escanear cada commit (SAST, dependencias y secretos) y guardar los registros del agente donde no pueda modificarlos. Además, un ingeniero aprueba todo cambio en las zonas sensibles.