Gemini 4 Carbon: encontrar un fallo y demostrar su arreglo

Google presentó Gemini 4 Carbon el 28 de octubre, con acceso inicial limitado a defensores y mejoras declaradas en ingeniería de software y ciberseguridad.

Ese recorrido tiene consecuencias prácticas. Un aviso de seguridad permite decidir dónde investigar. Una corrección permite actuar sobre el programa. Entre ambos pasos hace falta explicar qué falla, reproducirlo en un entorno autorizado y comprobar que el cambio conserva el funcionamiento que se necesita. La medida útil de un agente de seguridad es la calidad del arreglo que puede demostrar.

Tres pruebas que responden a preguntas diferentes

Google comunica estos resultados, que corresponden a tareas diferentes:

Fuente: Google, 28/10/2026. Porcentajes de éxito en evaluaciones distintas, realizadas según el fabricante sin las barreras de seguridad del modelo.

La página de SEC-bench Pro describe tareas de descubrimiento y generación de pruebas de concepto, con programas, límites de tiempo y un sistema que recoge los resultados. En la versión pública consultada no aparece Carbon. Por ello, el 88,2 % de esta tabla conserva la atribución a Google.

ExploitGym se centra en desarrollar formas de explotación a partir de vulnerabilidades de programas reales. Su documentación incluye aislamiento de red y configuración del entorno de evaluación. Resolver una tarea allí depende también del entorno de ejecución. Esa puntuación, por sí sola, no mide la protección de una aplicación desplegada.

Un caso documentado: corregir sin cambiar lo que funciona

CWE-bench ofrece un ejemplo público basado en blurhash-rs, una biblioteca que convierte cadenas de texto en las vistas borrosas que pueden mostrarse mientras carga una imagen. El caso utiliza una vulnerabilidad conocida, CVE-2023-42447. Algunas entradas malformadas podían provocar un fallo abrupto del decodificador.

La tarea exige devolver un error controlado ante esas entradas y conservar los píxeles producidos por las válidas. También exige mantener una interfaz compatible con los programas que utilizan la biblioteca. Es un ejemplo publicado de entrenamiento, no una demostración de que Carbon haya arreglado ese caso concreto.

El ejemplo aclara el problema de fondo. Eliminar una función puede hacer desaparecer el fallo y, al mismo tiempo, inutilizar la aplicación. Una reparación útil tiene que satisfacer ambas obligaciones: cerrar la vía problemática y conservar el servicio legítimo.

Artificial Analysis evaluó y publicó los resultados de CWE-bench, la prueba de Collinear AI. Su tabla del 28 de octubre incluye Carbon con un 71 % de éxito en el primer intento según las comprobaciones programadas de la evaluación. Esta contiene 120 tareas y añade un panel de tres jueces de IA. No publica allí el coste medio por ejecución de Carbon.

Acceso restringido y una tarifa de lanzamiento

Google anuncia una incorporación gradual de socios a través de Fairwind. Publica un precio introductorio de 2 dólares por millón de tokens de entrada y 10 por millón de salida. Su nota prevé pasar después a 4 y 20 dólares, respectivamente. El anuncio no fija el final de esa promoción ni una fecha general de acceso.

La página del programa Fairwind describe selección de organizaciones, controles de acceso y usos defensivos autorizados. Todavía presenta Argon como modelo del programa. Esas reglas explican el enfoque de acceso, pero las condiciones concretas que se ofrezcan para Carbon deberán comprobarse al solicitarlo.

Para una empresa, el precio por token sólo describe una parte del coste. Una investigación puede consumir muchas interacciones y necesitar revisión del equipo, capacidad de ejecución y pruebas. La comparación práctica tendría que incluir el coste de las correcciones aceptadas y el de los errores que pasan inadvertidos.

Qué debería cambiar en el trabajo de un equipo

La objeción más seria es que una reparación convincente puede seguir dejando una variante del fallo abierta. El equipo necesita saber qué propiedad de seguridad debe recuperar el programa y qué evidencia permite considerarla restaurada. Esa responsabilidad acompaña a la decisión de integrar el cambio.

Como criterio de adopción, conviene empezar con permisos acotados, conservar la propuesta y sus pruebas, y someter el resultado a revisión antes de incorporarlo al servicio. Este es un criterio editorial para evaluar la herramienta, no un procedimiento probado aquí con Carbon. Conecta con lo aprendido sobre los fallos de PHP y sobre los agentes que pueden cambiar sus controles. También depende de qué demuestra una restauración real cuando una intervención sale mal.

Carbon merece seguimiento por la posibilidad de reducir el trabajo entre detectar un problema y entregar una corrección comprobable. La decisión de utilizarlo debe apoyarse en arreglos verificables dentro del proyecto concreto, junto con límites de acceso y capacidad de recuperación. Esa será una evidencia más útil que una puntuación aislada.

Fuentes y alcance

Se consultaron el anuncio de Google del 28 de octubre, la página de Fairwind y las descripciones y resultados públicos de las tres pruebas enlazadas. Las cifras de SEC-bench Pro y ExploitGym se atribuyen al fabricante. No se ejecutó Carbon ni se reprodujeron las evaluaciones. El ejemplo de blurhash-rs explica una tarea publicada, sin atribuirle un resultado del modelo. Acceso y precios deben comprobarse al contratar.