Gemini Robotics 2: lo que muestran las cifras de DeepMind

Qué es realmente Gemini Robotics 2

El nombre no le hace ningún favor a nadie aquí, así que vamos con la versión sencilla. «Gemini Robotics 2» es el nombre de la familia y también el nombre de un modelo específico dentro de esa familia. Tres modelos se lanzaron juntos el mismo día, y cada uno hace un trabajo distinto.

Esta división importa, porque es la misma arquitectura que yo dibujaría para cualquier sistema de agentes serio. Un modelo razona sobre qué hacer, y hace seguimiento de si funcionó. Una pieza separada, más rápida, se encarga de ejecutar. DeepMind es explícito en que ER 2 «cede la ejecución de motores a cualquier modelo de visión-lenguaje-acción (VLA) de nivel inferior dado», es decir, el planificador se mantiene deliberadamente agnóstico respecto a las manos.

Un detalle en la documentación replantea todo el asunto: ER 2 está construido sobre Gemini 3.5 Flash. No es una derivada de nivel Pro. Tampoco es una arquitectura hecha a medida. Es un modelo de clase Flash, con razonamiento espacial, localización de momentos en vídeo y orquestación multi-robot ajustados encima. Cualquiera que haya seguido Gemini 3.6 Flash ya sabe más o menos cómo es el presupuesto de cómputo subyacente, y la línea Flash-Lite cuenta la misma historia.

El trabajo de señalar y de coordenadas viene del mismo linaje que la visión agéntica de Gemini. Y si estás valorando toda la familia, mantengo actualizada una lista de alternativas a Gemini.

La afirmación de control de cuerpo completo es real, y merece la pena aclararla. Las versiones anteriores solo controlaban la parte superior del cuerpo del humanoide, para trabajo de mesa. Esta también controla las piernas. El prompt de demo que publicó DeepMind es «pon la regadera en el contenedor verde de la balda de abajo», y el Apollo 2 de Apptronik camina hasta la mesa, recoge la regadera, se desplaza hasta las estanterías y la coloca. El mismo checkpoint del modelo también mueve un Franka Duo equipado con pinzas de dos dedos, que es la parte más discretamente impresionante de todo esto.

Las cifras que DeepMind publicó sobre sí mismo

Aquí está la tabla completa, exactamente como la reportó DeepMind. Los tres grupos de habilidades corren sobre un mismo checkpoint compartido, en tres cuerpos de robot distintos, y por eso la dispersión aquí resulta interesante en lugar de vergonzosa.

Lee juntos el extremo superior y el inferior del grupo de varios dedos, porque ese único par cuenta toda la historia de dónde está el aprendizaje robótico en 2026. Desenroscar una bombilla es 92%. Enroscar una es 36%. Ambas usan la misma mano SharpaWave de cinco dedos y 22 grados de libertad, en el mismo robot. Lo que cambia es el movimiento. Desenroscar es holgado y perdona errores; enroscar exige mantener una alineación mientras aplicas torsión. Uno es agarrar. El otro es un problema de control.

El grupo de pinza supera al grupo de manos en casi todo, y ese es el segundo dato que merece la pena detenerse a considerar. Una pinza Robotiq de dos dedos en el Franka Duo logra un 89,6% en inserción de precisión, mientras que la mano antropomórfica solo logra un 40% con una bolsa ziplock. Más grados de libertad compraron peores resultados en el trabajo fino. Al menos por ahora.

Y DeepMind lo dijo ella misma. El pie del gráfico dice: «Aunque Gemini Robotics 2 logra una tasa de éxito media a alta en tareas de destreza de cuerpo completo y basadas en pinza, la manipulación destra con varios dedos sigue siendo un reto». En otra parte de esa misma página: «nuestros robots tienen más margen de avance en velocidad de movimiento», y la destreza a nivel humano se plantea como un objetivo, no como una afirmación.

Por qué una sola cifra combinada habría escondido todo esto

Promedia esas cinco tareas de varios dedos en una sola cifra y acabas en algún punto de la mitad de los cuarenta, sin haber aprendido nada. No sabrías que el modelo está casi resuelto en un movimiento y apenas funcional en otro. Tampoco sabrías en torno a qué tarea evitar diseñar tu producto.

Esto no es en absoluto un problema de robótica. Es el estado por defecto del marketing de IA en cualquier categoría, la mía incluida, donde una sola cifra de desvío de nivel 1 esconde exactamente la misma dispersión. Muévete tú mismo las cifras y observa qué fácil es dirigir el titular:

Prueba "Solo las 4 favorables" y sale una cifra que cualquier equipo de marketing imprimiría con gusto. Mismo modelo, mismo día, mismo laboratorio. No se fabricó absolutamente nada para producirla. Ese es el truco, y está disponible para cualquier proveedor que reporte una sola cifra.

El dato más interesante trata sobre humanos, no sobre robots

Enterrada en los benchmarks de ER 2 hay una comparación que DeepMind ejecuta de tres formas. Mide qué tan bien el modelo de razonamiento dirige a un ejecutor posterior, y lo que cambia es ese ejecutor: primero un robot real, luego uno simulado, luego un teleoperador humano.

El mismo planificador es 14 puntos mejor dirigiendo a una persona que dirigiendo a un robot. El modelo no es peor en uno de los dos casos. El humano al otro lado simplemente absorbe la ambigüedad, se recupera de un mal agarre, rellena cualquier intención que la instrucción dejó fuera.

Un comentarista de Reddit que veía las imágenes de la demo llegó a la misma conclusión desde fuera:

"The bottleneck seems to be software. So until we get ai good enough to pilot a robot, it's going to remain slow.

If you see robots piloted by humans, they are much faster."

u/dranaei, Reddit

Este es el hallazgo que pegaría en una pared, y en realidad no es un hallazgo de robótica. Es el argumento del copiloto de IA con una cifra adjunta. Un modelo que planifica y luego cede el control a un humano capaz supera al mismo modelo manejando el efector final por sí solo, y la diferencia es medible. En trabajo de soporte, esa es la diferencia entre un agente que redacta una respuesta para que alguien la envíe, frente a un agente que responde por su cuenta. La respuesta honesta sobre cuál rinde mejor es la misma que la de DeepMind, es la que tiene una persona en el bucle, hasta que las cifras por tarea digan otra cosa.

Nada de esto es un argumento contra la autonomía. Es un argumento a favor de conocer la cifra antes de elegir, y esa cifra se mueve rápido, tan rápido que los mejores agentes de IA de hace seis meses no son los que elegirías hoy.

El resto del conjunto de comparación de ER 2 es sólido, y merece la pena reportarlo de forma justa:

La clasificación de progreso es el margen más amplio de toda la página: 57,4% frente al 46,2% del mejor modelo no robótico. La métrica es «puedes decir hasta dónde has llegado en una tarea», puntuada por fotograma en cinco categorías. Poco glamurosa, y es exactamente lo que un agente necesita saber antes de decidir si sigue adelante o pide ayuda. DeepMind también reporta un 91,3% de precisión en la localización de momentos, con una distancia media absoluta de 0,96 segundos, a 4 veces la velocidad de ejecución de las categorías de modelos más grandes.

También vale la pena señalar que ese mismo 57,4% significa que se equivoca sobre el progreso más o menos cuatro de cada diez veces. Lo mejor de su clase, y aun así se equivoca con esa frecuencia, lo cual es un estado normal en este campo. Es también exactamente el tipo de cosa que una afirmación de una línea sobre «estado del arte» borra.

El salto en seguridad del que nadie habla

Esta es la cifra que me hizo incorporarme de golpe. No la he visto todavía cubierta en ningún sitio.

Gemini Robotics ER 1.6 seguía las instrucciones de seguridad el 47,2% de las veces. Ese modelo se lanzó en abril de 2026, es decir, hace cuatro meses, y quedó por debajo tanto de Opus 5 como de GPT 5.6 Sol en ambas métricas de seguridad. Un modelo ajustado para robótica, peor en seguridad robótica que los modelos de texto de uso general contra los que se le comparó.

ER 2 lo arregla a fondo, hasta el 97,9% y el 93,0%. Bien. Sin embargo, la lectura útil es lo que la cifra de la generación anterior dice sobre confiar en una etiqueta de versión. «El último modelo de robótica de un laboratorio puntero» era, hasta la semana pasada, algo que seguía una restricción de seguridad menos de la mitad de las veces. DeepMind también lanzó un nuevo benchmark para esto, ASIMOV-Agentic, publicado como conjunto de datos público. Mide si el agente de razonamiento rechazará una llamada a herramienta insegura, si puede predecir que una tarea es imposible, y luego si pide ayuda a un humano cuando no está seguro.

Rechazar, predecir el fallo, escalar cuando hay incertidumbre. Eso describe mejor a un agente de soporte bien construido que la mayoría de la documentación de IA de soporte, y se traslada directamente a la gestión de escalamiento. El traspaso es una disciplina propia por encima de eso, y el traspaso de chat es el caso que la mayoría de los equipos hacen mal primero.

Merece la pena ser preciso sobre los límites aquí. El blog afirma que ER 2 es el modelo de robótica más seguro de DeepMind hasta la fecha, pero no publica ninguna puntuación numérica de los resultados de ASIMOV-Agentic en sí. Esos están en un informe técnico de seguridad separado. Y la documentación para desarrolladores es tajante sobre dónde cae la responsabilidad: «es tu responsabilidad mantener un entorno seguro alrededor del robot».

Lo que cuesta, y las trampas de la documentación

Solo ER 2 tiene un precio. Los dos modelos que tocan hardware no tienen ninguno en absoluto, por la simple razón de que no se pueden comprar.

El precio se duplicó. ER 2 cuesta 2 veces lo que ER 1.6 tanto en entrada como en salida, aunque la tarifa plana de entrada implica que el trabajo con mucho audio ve una subida relativa menor que el trabajo con visión. La ventana de contexto no creció en absoluto. También hay un hermano de streaming, gemini-robotics-er-2-streaming-preview, a la misma tarifa titular, sin nivel Batch ni caché.

Cuatro cosas en la documentación que te costarán una tarde si no las lees primero:

1. Una clave de API sin restricciones recibe un 403 rotundo. Robótica es la única superficie de Gemini que rechaza una clave por defecto, así que añade restricciones en AI Studio antes de tu primera llamada.
2. El endpoint de streaming limita la entrada de imagen a JPEG, 1 fotograma por segundo. Lo cual resulta extraño frente a todo el discurso de tiempo real. Un robot que transmite fotogramas de cámara a no más de uno por segundo.
3. El endpoint de streaming elimina las salidas estructuradas y la ejecución de código. Así que la ruta de esquema JSON pertenece al modelo sin streaming, y la ruta de visión agéntica también.
4. La documentación recomienda un nivel de razonamiento medium para la latencia, y el ejemplo de introducción viene con high. Cópialo y pégalo, y heredas el valor por defecto lento.

También hay un aviso de privacidad adjunto a estos modelos que ninguna página normal de Gemini lleva. Como los modelos «aprovechan datos de vídeo y audio para operar y mover tu hardware», Google exige que no permitas que haya personas identificables presentes alrededor del robot hasta que hayan sido notificadas y hayan dado su consentimiento, y además pide difuminado de rostros. Pon eso junto al «se usa para mejorar nuestros productos: sí» del nivel gratuito. Un robot de nivel gratuito con una cámara apuntando a personas se convierte entonces en un problema de consentimiento, no de cuota.

Y una nota de calendario que merece la pena anotar: gemini-robotics-er-1.6-preview se apaga el 31 de agosto de 2026. ER 1.5 ya se retiró en abril. Así que, dos endpoints retirados en un año, y todo el código de modelo actual todavía lleva el sufijo -preview sin ningún alias estable al que fijarse.

Adaptación a robots nuevos, y la parte multi-robot

Gemini Robotics On-Device 2 es la pieza que encuentro más silenciosamente significativa. Se ejecuta localmente, hereda el trabajo de transferencia de movimiento de Gemini Robotics 1.5, y se adapta a un robot bi-brazo completamente nuevo «con solo unas pocas horas de tiempo de adaptación, típicamente con menos de 200 ejemplos». Formas nuevas, sensores nuevos, grados de libertad que no coinciden.

Menos de 200 demostraciones para poner en marcha un nuevo cuerpo de robot, esa es la cifra que cambia la economía del campo. Las tareas de esa cuadrícula corrieron en plataformas Dexmate, SO101 y Trossen, ninguna de ellas el humanoide insignia. Un panel muestra un brazo robótico haciendo clic en una casilla «soy un robot», que asumo es una broma, y que aprecio.

La colaboración multi-robot es la otra capacidad nueva. Robots que se comunican, reconocen las fortalezas físicas del otro, y luego se delegan tareas entre sí. En la demo, un humanoide Apollo 2 trabaja junto a un brazo Franka, con un monitor que muestra lo que ve el modelo.

DeepMind agradeció a Apptronik, Boston Dynamics y Agile Robots como socios, y en una demo aparte, un Spot de Boston Dynamics va a buscar palomitas mediante APIs de Spot orquestadas. En el lado del hardware: Apptronik levantó una Serie A-X de 520 millones de $ en febrero de 2026, lo que lleva su total a cerca de 1.000 millones de $. Merece la pena señalar que Apollo 2 es una plataforma de recolección de datos, no la unidad comercial. La comercial es Apollo 3, y no tiene fecha anunciada. Sin especificaciones publicadas y sin precio publicado, de ninguno de los cuatro proveedores de hardware involucrados.

Lo que dijeron realmente los profesionales

El hilo de Hacker News llegó a 619 puntos y 553 comentarios, y es mejor lectura que cualquiera de las coberturas. El comentario más útil ahí vino de alguien que trabaja en estos modelos:

"Plus we have no good reliable accuracy testing data in most cases (most tests occur on a few demos, but that isn't a good representation of how must things work), popular benchmarks, such as libero have been saturated, and nearly everything gets 95% there, most companies and researchers have their own benchmarks here."

adityashankar, Hacker News

Benchmarks saturados, y todo el mundo calificando su propia tarea. Eso describe también la evaluación de IA de software, casi palabra por palabra, y es por lo que la propia guía de evaluación de OpenAI se apoya tanto en construir tu propio conjunto de evaluación en lugar de confiar en una clasificación pública.

La crítica más aguda no trata sobre el modelo en absoluto. Trata sobre la gramática del vídeo:

"This is why we need long continuous shots of robots interacting doing tasks, rather than the sizzle reels with 5 second shots. The long shots tell the true story of how far along the technology is, while the short shots make it look way more advanced than it really is. Still, great to see the progress being made."

u/edgroovergames, Reddit

Un comentarista de HN fue más allá, calificando las demos de «pick and place glorificado con bajas tasas de éxito en un robot innecesariamente complejo», y diciendo que preferiría las imágenes abiertamente teleoperadas de un competidor, porque se acercaban más a un despliegue real. Duro. Tampoco irrazonable, dado el 45,7%.

Esa cifra del 36% se recogió después como evidencia de un argumento más amplio:

"A 36% success rate on screwing in a light bulb means there's probably something to LeCunn's take that VLM/VLA models aren't going to be the thing powering tomorrow's robots, but only time will tell."

cowboy_henk, Hacker News

La mejor réplica llegó en una línea, y es la que yo apostaría:

"It's still very early days. There are many benchmarks that LLMs scored 36% on just 18 months ago that they're now at 100% on."

heaney-555, Hacker News

Y luego un roboticista, explicando por qué «lento y cuidadoso» es una clase de problema distinta a «rápido y fluido»:

"An algorithm to fold tshirts 90% of the time is easy. The cloth hangs down by gravity and you can just look for right angles (corners), find their coordinates with binocular matching, and move them to meet each other. Getting 99%, or folding them quickly, so that the fabric is actually moving instead of just hanging still- incredibly, incredibly more complex."

hwillis, Hacker News

También hubo una buena dosis de «¿no lo había mostrado ya Figure?» ahí dentro, lo cual me lleva a la comparación que realmente importa.

Nadie más publica esta tabla

Fui a buscar las cifras equivalentes por tarea de todos los demás laboratorios de este espacio. Esto es lo público, todo ello.

DeepMind es el único que puso tasas de fallo absolutas por tarea en su propia página de lanzamiento. Figure nombra tareas de destreza y muestra una carrera de cuatro minutos con un lavavajillas en vídeo, sin adjuntar ninguna cifra a nada de eso. Tesla nunca ha nombrado un modelo de Optimus, en absoluto. Physical Intelligence sí grafica tasas por tarea, pero frente a una línea base de un especialista en RL, y con los valores renderizados en el cliente en lugar de declarados.

Así que la lectura honesta de Gemini Robotics 2 no es «el robot de Google va por detrás». Google es el único que te muestra dónde está realmente su robot, y luego recibe críticas por las cifras que decidió divulgar. Ese es un mal incentivo. Si se mantiene, el siguiente laboratorio simplemente publicará vídeos.

Qué significa esto si estás comprando agentes de IA

Yo no trabajo con robots. Construyo agentes de IA que gestionan tickets de soporte, y este lanzamiento sí cambió lo que creo que un proveedor debería estar obligado a mostrarme.

Hubo un cliente, un equipo danés de B2B de telemática vehicular que gestionaba unos 200 tickets al mes en Zendesk y escalaba hacia 2.000, cuyo agente empezó a decirle con confianza a los clientes «sí, damos soporte a su modelo de coche» para marcas que no estaban en su base de datos. La base de conocimiento decía «damos soporte a todos los modelos». El bot se lo creyó. Su propio resumen de esa configuración inicial fue «ensayo y error al principio». Ese tipo de ticket habría marcado un cero rotundo en una tabla por tarea, y en la cifra combinada era simplemente invisible. Esta es la forma de fallo habitual en la automatización del servicio al cliente, nada exótico, y por eso la prevención de alucinaciones es más una cuestión de configuración que de modelo.

Por eso cada despliegue de eesel corre primero una simulación contra el propio historial de tickets del cliente. Se toma un lote de tickets resueltos, se genera lo que sea que el agente habría dicho, se compara eso con lo que el humano realmente envió, se puntúa, y luego se produce un informe de brechas antes de que intervenga un solo cliente real. Es la tabla de DeepMind, solo que construida a partir de tus tickets en lugar de bombillas. Una responsable de CX en una marca de suplementos D2C planteó el requisito mejor de lo que yo podría:

"The AI will never be able to answer 100% of the questions... I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

Tres cosas que me llevaría de este lanzamiento a cualquier compra de agente de IA, física o no:

1. Pide la tabla por tarea, no el titular. Cuando un proveedor cita una sola cifra de desvío, pide que se desglose por intención o por tipo de ticket. La verdad está en la dispersión, y las métricas de rendimiento de IA solo son útiles a ese nivel de detalle. Lo mismo aplica a la resolución en el primer contacto.
2. Prueba con tu propio historial antes de lanzar. Un benchmark ejecutado sobre las tareas de otra persona no predice nada sobre los casos límite de tu política de reembolsos. El mismo instinto que las pruebas adversarias, y la razón por la que evaluar agentes es mejor que confiar en una demo.
3. Diseña para la tarea del 32%, no para la del 92%. Sabe qué trabajo debería rechazar el agente. Fija umbrales de confianza de forma deliberada, mantén el traspaso limpio. Prevenir una respuesta equivocada dicha con confianza vale más que un punto de cobertura.

Ese último punto es todo el juego. Un agente que resuelve el 60% de los tickets y luego escala limpiamente el resto es un mejor producto que uno que intenta el 100% y se equivoca en uno de cada cinco, y los clientes me lo dicen constantemente. Las matemáticas del coste por resolución también salen mejor, una vez que incorporas el precio de los tickets que crea una mala respuesta.

Si quieres el panorama de medición más completo, mi artículo sobre evaluación del servicio al cliente profundiza más de lo que puedo aquí, y también la comparación de coste de agente frente a humano. Y si todavía estás eligiendo un modelo base, qué LLM conviene al soporte es una mejor pregunta de partida que cualquier benchmark de robótica.

Prueba eesel

Si estás buscando un software de atención al cliente agéntico, y quieres la honestidad por tarea que este artículo lleva defendiendo, eso es más o menos para lo que se construyó eesel. Se conecta a Zendesk o a cualquier helpdesk que ya uses, Freshdesk incluido. Aprende de tus macros y de tus tickets pasados. Luego ejecuta una simulación sobre tu historial real, así que puedes ver la forma de su precisión por tipo de ticket antes de que responda nunca a un cliente.

La diferencia concreta: decides tú qué tipos de ticket toca y cuáles deja en paz, y obtienes recuentos de aprobación y rechazo por acción en lugar de un solo porcentaje de desvío. Gridwise vio resuelto el 73% de las solicitudes de nivel 1 en el primer mes, y sabía cuáles eran el 27% que no. El precio es por ticket, así que no estás comprando plazas para un agente que solo gestiona una porción de la cola.

Prueba eesel gratis, o simplemente apúntalo a cien de tus tickets antiguos y mira qué dice el informe de brechas.