Imagina que tienes un restaurante con sistema de reservas online. Un cliente potencial le dice a su teléfono: «Reserva mesa para dos el martes a las dos en el Restaurante X.» El teléfono abre Chrome, navega a tu web, encuentra el formulario de reservas, selecciona fecha y hora, rellena los datos del cliente y confirma la reserva. El cliente recibe la confirmación sin haber tocado nada. Tú recibes la reserva.
Eso no es ciencia ficción. Es exactamente lo que Chrome auto-browse hace, y llega a los primeros móviles Android a finales de junio de 2026.
Qué es Chrome auto-browse y cómo funciona
Chrome auto-browse es una función de Gemini integrada en Chrome para Android que navega webs y completa tareas por delegación del usuario. El usuario describe lo que quiere en lenguaje natural: reservar una cita, buscar disponibilidad de hotel, solicitar un presupuesto, renovar una licencia, comparar precios. El agente lo ejecuta en tiempo real, navegando páginas reales, rellenando formularios y completando flujos de varias pantallas.
Para hacerlo, Gemini lee el contenido de la página, identifica los elementos interactivos como formularios, botones y calendarios, y rellena los campos usando los datos del usuario almacenados en el gestor de contraseñas de Google y en su perfil personal. El usuario puede seguir el progreso en notificaciones mientras el agente trabaja en segundo plano. Antes de confirmar una compra o cualquier acción irreversible, el agente se detiene y pide confirmación explícita.
Google anunció esta función el 12 de mayo en el Android Show 2026, bajo el paraguas de lo que llama Gemini Intelligence. El despliegue empieza a finales de junio en los primeros Samsung Galaxy S26 y Google Pixel 10, y se extenderá a lo largo del año a relojes, coches, gafas y portátiles Android. La función requiere suscripción a Google AI Pro (19,99 dólares al mes) o AI Ultra (249,99 dólares al mes).
Lo relevante para cualquier negocio con presencia online es que no existe ningún proceso de adhesión ni registro para que tu web sea compatible. El agente navega cualquier web pública que Chrome pueda abrir. No hay una lista de partners ni un directorio de negocios participantes. La diferencia entre que el agente pueda completar una tarea en tu web o no depende exclusivamente de cómo está construida técnicamente.
El cambio de fondo: de la citación a la transacción
Durante dos años, la pregunta sobre visibilidad en IA ha sido una sola: ¿cita el sistema tu contenido? A finales de junio de 2026, esa pregunta se duplica. La segunda es más incómoda: cuando el agente llega a tu web para completar una reserva o una compra, ¿puede hacerlo?
Para ser citado en una respuesta de IA, lo que importa es la calidad y estructura del contenido. Para que el agente complete una transacción, lo que importa es la arquitectura técnica del flujo: formularios, botones, velocidad de carga, comportamiento de modales y ventanas emergentes. Son dos dimensiones distintas de la visibilidad online, y a partir de ahora conviven.
Y aquí está el detalle que cambia las reglas: si el agente no puede completar la reserva en tu web, no se detiene ni da error. Busca el siguiente resultado y reserva allí. La reserva va a tu competidor. Y tú no ves nada: no hay un evento de carrito abandonado, no hay una sesión sin conversión, no hay ninguna señal en Analytics ni en Search Console que indique que un agente intentó completar una transacción y no pudo. El tráfico que no llegó es completamente invisible.
Desde la perspectiva del usuario tiene toda la lógica: si quiero reservar y el agente no puede hacerlo en un sitio, que lo intente en el siguiente. Yo obtengo lo que quería. Pero desde la perspectiva del negocio que perdió esa reserva, el problema es que nunca sabrá que la perdió ni por qué. Meses después, el propietario nota que las reservas online han bajado y no puede identificar la causa.
Los fallos técnicos que bloquean al agente
La mayoría de los problemas que impiden a un agente completar una transacción no son nuevos ni complejos. Son los mismos que los equipos de accesibilidad llevan años señalando, y que en la práctica siguen sin resolverse en la gran mayoría de webs.
Renderizado dependiente de JavaScript. El agente lee el HTML inicial de la página. Si el formulario de reservas o el botón de acción solo aparece después de que se ejecute JavaScript, el agente ve una página vacía. Muchos constructores visuales de webs generan este tipo de renderizado por defecto.
Formularios sin etiquetas. Un campo de formulario sin etiqueta asociada es un campo que el agente no puede identificar. No sabe si ahí va el teléfono, el email o el nombre del cliente. Con cinco campos sin etiquetar, la probabilidad de fallo se multiplica.
Botones que no son botones. Un botón construido con un <div> o un <span> estilizado en lugar de un elemento <button> real es un botón que el agente no reconoce como elemento clicable. Es uno de los errores más frecuentes en webs construidas con herramientas visuales.
CAPTCHAs en el flujo de reserva. Un CAPTCHA es un bloqueo total. El agente no lo resolverá. La reserva falla en ese punto sin posibilidad de recuperación.
Muros de cookies que bloquean el contenido. Si la web muestra un banner de cookies que oculta todo el contenido hasta que el usuario hace clic en aceptar, el agente necesita gestionar ese paso antes de poder continuar, con resultados variables según cómo esté implementado el banner.
Ventanas modales que atrapan el flujo. Un modal que aparece a mitad del proceso de reserva y no puede cerrarse de forma limpia deja al agente sin salida. El flujo queda interrumpido sin que el usuario sepa qué ha pasado.
Velocidad de carga insuficiente. Si la página tarda demasiado en cargar, el agente puede abandonar antes de que el contenido esté disponible, especialmente en conexiones móviles. Es el mismo problema que ya afecta a la indexación y a la citación en resultados de IA.
Muros de registro sin credenciales guardadas. Si completar la reserva requiere iniciar sesión y el usuario no tiene las credenciales guardadas en el gestor de contraseñas, el agente se detiene. Para negocios locales con sistemas de reserva propios, este es uno de los fricciones más habituales.
Qué hacer con esta información
La revisión técnica necesaria no requiere rehacer la web. Requiere comprobar que los formularios tienen etiquetas correctas, que los botones son elementos HTML reales, que el contenido principal carga sin depender de JavaScript, que no hay elementos que bloqueen el flujo, y que la velocidad de carga es razonable en móvil. Son los mismos criterios de accesibilidad que llevan años en las guías técnicas de Google y que pocas webs cumplen al cien por cien.
La diferencia ahora es que el coste de no cumplirlos ya no es solo perder usuarios con necesidades de accesibilidad específicas. Es perder reservas sin saberlo, a favor del competidor cuya web sí funciona cuando el agente llega a ella.
El despliegue inicial de Chrome auto-browse en Android está limitado a suscriptores de pago y a los primeros modelos de Samsung y Pixel. Pero el horizonte de cientos de millones de dispositivos Android a lo largo de 2026 hace que esta conversación tenga urgencia real, no solo teórica.
Artículos relacionados en The Clic Lab:
