La semana pasada Google DeepMind abrió Gemini Robotics-ER 1.5 a desarrolladores en preview. No es un gadget para tu tienda online ni un plugin de WordPress: es un modelo de razonamiento embebido pensado para que un robot planifique antes de tocar nada. Si llevas años metido en automatización web, el discurso te sonará familiar; solo que aquí el «navegador» es una cámara y el «clic» es un actuador.
Te cuento qué anuncian, qué encaja con lo que ya vemos en agentes de software y por qué me interesa mirarlo aunque no tengas un brazo robótico en el almacén.
Dos modelos, dos trabajos
DeepMind separa el problema en dos capas, como resume Ars Technica: Gemini Robotics-ER 1.5 razona sobre el espacio, el objetivo y el progreso; Gemini Robotics 1.5 es el que traduce esa intención en acciones concretas sobre hardware real. El primero ya está accesible en Google AI Studio; el segundo sigue restringido a probadores de confianza.
Esa división no es capricho de marketing. En proyectos web hacemos algo parecido cuando separamos un LLM que planifica tareas de la capa que ejecuta APIs, rellena formularios o lanza scripts. Si mezclas planificación y ejecución en un solo bloque opaco, depurar es un infierno.
«Pensar» con presupuesto: latencia frente a precisión
En el blog de Google Developers insisten en un detalle que a mí me parece el más transferible al día a día: un «thinking budget» configurable. Puedes pedir respuestas rápidas para tareas reactivas (localizar un objeto) o dejar que el modelo invierta más tiempo en planificar montajes largos o reorganizar un espacio según una foto de referencia.
En hosting y mantenimiento web llevamos años negociando el mismo trade-off: más caché y menos cómputo versus más precisión en invalidaciones y despliegues. Verlo explícito en un modelo de robótica confirma que el sector agentic va hacia controles finos, no hacia «a más tokens, mejor».
Herramientas, búsqueda y límites físicos
Gemini Robotics-ER 1.5 puede llamar herramientas nativas (Google Search, funciones definidas por el desarrollador) y encadenar bucles de planificación con detección de éxito. También mencionan filtros de seguridad semántica mejorados para rechazar planes imposibles, como sobrepasar la carga útil del robot.
Traducido a pymes digitales: un agente que consulta documentación externa antes de actuar y que tiene guardrails sobre lo que no debe intentar. La diferencia es que un error en un robot puede romper algo físico; en tu WooCommerce puede vaciar stock o duplicar pedidos. La lección es la misma: el razonamiento sin límites operativos es una demo bonita, no un producto.
Qué puedes sacar en claro si no programas robots
- Agentes en capas: planificador + ejecutor. Si estás probando IA en soporte o backoffice, no metas todo en un solo prompt monolítico.
- Presupuesto de inferencia: define cuándo necesitas respuesta inmediata y cuándo puedes esperar a un plan más sólido.
- Verificación de resultado: los bucles largos solo funcionan si detectas si la tarea terminó bien; en web eso son logs, tests de regresión o comprobaciones en base de datos.
- Preview ≠ producción: ER 1.5 está en preview; el modelo de acción física aún no es para cualquiera. Con los agentes de código pasa igual: lo que brilla en demo suele necesitar meses de hardening.
Expectativas realistas
Ars Technica lo dice sin rodeos: estamos lejos de un robot doméstico que doble la colada. Lo relevante hoy es que el razonamiento simulado que mejoró los chatbots empieza a aplicarse a entornos físicos con métricas publicadas y API para experimentar. Para quien vende servicios digitales, es una señal de hacia dónde se moverán las integraciones de Google Cloud y las expectativas de clientes que ya piden «agentes» en todos sitios.
En mi experiencia, cuando un anuncio mezcla robótica y IA generativa, el cliente final acaba preguntando si puede «automatizarlo todo» en su web. Este tipo de lanzamientos obliga a explicar qué parte es percepción, qué parte es planificación y qué parte sigue siendo ingeniería a medida.
Si mañana tu proveedor de automatización te propusiera un agente con «modo rápido» barato y «modo planificación» caro para cambios en catálogo o migraciones, ¿sabrías en qué tareas pagarías la latencia extra y en cuáles no?