Grok Bot: agentes con su propio ordenador, y una letra chica que conviene leer

Grok Bot son agentes que inician sesión en tus herramientas y hacen el trabajo dentro de ellas, en un ordenador en la nube que sigue funcionando con tu portátil cerrado. Se anunció en beta el 11 de agosto de 2026 y no es un modelo nuevo ni un chat: es un producto para delegar tareas de varios pasos.

Hay mucho escrito sobre lo que promete. Yo me voy a detener en algo que está en la documentación oficial, que cambia bastante cómo deberías usarlo, y que no he visto explicado en español: todos tus bots comparten el mismo ordenador, las mismas sesiones de navegador y las mismas credenciales.

Qué es exactamente

La definición de la propia documentación es corta: "los Bots son compañeros de IA a los que puedes darles trabajo real. Los Bots pueden iniciar sesión y usar apps y sitios web igual que tú, en un ordenador persistente en la nube".

Las tres piezas que lo distinguen de un chat:

• Un ordenador propio en la nube. Persistente, no una sesión que se evapora. Los archivos, el estado del navegador y los inicios de sesión están pensados para sobrevivir a actualizaciones y recuperaciones.
• Trabaja sin API. El bot navega, hace clic y escribe como lo harías tú, así que puede operar herramientas que no exponen ninguna integración.
• Sigue trabajando sin ti. Cierras el portátil y la tarea continúa en la nube.

Puedes hablarle como a un compañero, y los bots pueden hablarse entre ellos: comparten contexto en hilos, se pasan trabajo y coordinan en grupo. También aprenden por demostración: le enseñas una tarea una vez, la guarda como rutina y la repite bajo demanda o en un horario.

Las tres formas en que toca tus herramientas

Esto importa más de lo que parece, porque determina qué tan frágil es cada automatización:

1. Navegador. Un navegador persistente con tus sesiones abiertas. Es lo que le permite usar cualquier cosa, y también lo más quebradizo.
2. Línea de comandos. Terminal directa en su ordenador.
3. Conectores. Integraciones estructuradas con servicios soportados.

La documentación es explícita sobre cuál preferir: "prefiere un conector cuando haya uno disponible: suele ser más fiable que hacer clic por un sitio web". Traducido, la demo de "usa cualquier app sin API" es real, pero es el camino de peor calidad. Si tienes conector, úsalo.

Si vienes del mundo de MCP, la idea de conector te va a sonar: es el mismo problema, dar al agente una vía estructurada en vez de dejarlo adivinar en una interfaz pensada para humanos. La diferencia es que aquí el agente puede caer al navegador cuando no hay conector, en vez de quedarse sin poder hacer nada.

La letra chica: un solo ordenador para todos tus bots

Aquí está lo que me hizo escribir este artículo. Cito la documentación de aprobaciones y seguridad, y es una frase sin ambigüedad:

No uses Bots separados como frontera de seguridad.

El motivo está en cómo se asigna el ordenador. No es un ordenador por bot: es un ordenador por cuenta de usuario. De ahí se derivan tres cosas concretas:

• Los archivos son visibles para todos tus bots.
• Las cookies y sesiones iniciadas del navegador se comparten.
• Las credenciales de línea de comandos están disponibles para todo el roster.

Cada bot tiene su propia pantalla dentro de esa máquina compartida, y eso genera la ilusión de aislamiento. No lo es. La regla práctica que da la documentación: trata cualquier login o archivo que pongas en ese ordenador como disponible para todos tus bots.

Por qué es un problema real. El patrón natural al empezar es crear un bot por área: uno para el CRM, otro para facturación, otro para soporte. Suena a separación de privilegios y no lo es. Si el bot de facturación inicia sesión en el banco, esa sesión queda disponible para el bot de soporte. Si esperabas que el bot de marketing no pudiera tocar producción, no hay nada en el producto que lo impida.

Lo que la documentación recomienda hacer en su lugar es manual y poco glamuroso: cerrar sesión en un servicio cuando ya no deba estar disponible, borrar los archivos temporales sensibles al terminar, y revocar la autorización de un conector en el servicio de origen cuando ya no haga falta.

El modelo de aprobaciones, y su límite

El producto pide aprobación explícita antes de ciertas acciones. La documentación sugiere poner frontera en estas: enviar mensajes o invitaciones, publicar contenido, compras y transferencias, borrar o sobrescribir datos, cambiar permisos, cambios en producción y aceptar términos legales.

Es una lista sensata. Pero hay una frase que conviene leer dos veces:

Una aprobación controla la acción propuesta. No revierte el trabajo ya completado.

Es decir, la aprobación es una compuerta antes del paso siguiente, no un botón de deshacer. Si el agente hizo quince pasos y el dieciseisavo es el que te pide permiso, los quince anteriores ya ocurrieron. Con un agente que opera dentro de tus sistemas reales, esa distinción es la diferencia entre un susto y un incidente.

La otra regla que dan, y que resume bien el riesgo: no apruebes acciones cuyo objetivo o efecto no puedas identificar.

Contraseñas: lo que sí está bien resuelto

Este punto me parece correcto y conviene reconocerlo. El modelo no recibe tus contraseñas. Ante una contraseña, una passkey, un código de dos factores, un CAPTCHA o una confirmación de pago, el bot te cede el control del ordenador: escribes tú y le devuelves el mando. Para conexiones soportadas hay entrada de credenciales enmascarada, cuyos valores quedan fuera de las transcripciones y de la visibilidad del modelo.

La regla que acompaña a esto es la que más gente va a saltarse por comodidad: no envíes una contraseña ni un código de un solo uso en el chat normal.

Conviene añadir algo que la documentación también admite: los sitios pueden bloquear la automatización, exigir CAPTCHAs o pedir inicios de sesión nuevos, y los bots no deben saltarse verificaciones pensadas para humanos. Un agente que navega por ti vive en tensión permanente con las defensas antibot de medio internet.

Qué necesitas para usarlo

Está en beta temprana, y el acceso va atado a planes de gama alta:

Dos cosas que llaman la atención de esa tabla. La primera es que no hay versión para Linux, lo cual es curioso en un producto cuya propuesta es dar ordenadores en la nube a desarrolladores.

La segunda es el detalle de privacidad: el modo de privacidad heredado no está soportado, así que si lo usabas para que tus conversaciones no se almacenaran, con Grok Bot no es una opción.

Por qué los planes se llaman "Cursor"

Si te chocó ver Cursor Ultra y Cursor Teams Premium como planes de un producto de SpaceXAI, no es una errata. La propia documentación de Grok Bot remite a la política de privacidad y a los controles de cuenta de Cursor para lo contractual.

El contexto lo dieron los medios en su momento: SpaceX se fusionó con xAI a comienzos de 2026 y acordó la compra de Anysphere, la empresa detrás de Cursor. De ahí el nombre SpaceXAI, y de ahí que la facturación cuelgue de los planes de Cursor.

Si quieres los precios de esos planes al día, los mantengo en el artículo de precios de Cursor, donde también está el detalle de las dos bolsas de uso, que es lo que más confunde de su facturación.

Mi lectura

Grok Bot no es un modelo mejor: es una apuesta por mover el producto de "redactar trabajo" a "hacer trabajo". Esa es la dirección de toda la industria ahora mismo, y la ejecución concreta aquí, un ordenador persistente al que el agente entra como entrarías tú, es la vía más directa y también la más burda. Funciona con todo justamente porque no depende de que nadie haya construido una integración.

El precio de esa generalidad es el modelo de seguridad. Un ordenador por cuenta, con todas las sesiones vivas y todos los archivos a la vista, es una superficie enorme para confiársela a un sistema que decide solo qué paso dar. No lo digo yo: la documentación lo dice con todas las letras y pide que no lo trates como una frontera.

Mi recomendación, si vas a probarlo, es aburrida: una cuenta separada de la que usas para todo, credenciales de servicios de prueba, y nada de producción hasta que entiendas cómo se comporta. Y si tu instinto era crear un bot por dominio para aislar riesgos, cámbialo: ese aislamiento no existe.

Si quieres el marco conceptual de fondo, antes de este producto concreto, lo desarrollo en qué es un agente de IA.

Preguntas frecuentes

¿Qué es Grok Bot?

Es un producto de SpaceXAI, en beta desde el 11 de agosto de 2026, formado por agentes que trabajan en un ordenador persistente en la nube. Inician sesión en tus aplicaciones y sitios web y ejecutan tareas de varios pasos, incluso con tu equipo apagado.

¿Grok Bot necesita que mis herramientas tengan API?

No. Puede operar cualquier herramienta usando el navegador, como lo harías tú. Aun así, la documentación recomienda usar un conector cuando exista, porque es más fiable que hacer clic por una interfaz.

¿Cada bot tiene su propio ordenador?

No, y es el punto que más conviene entender. El ordenador se asigna a tu cuenta de usuario, no al bot. Todos tus bots comparten archivos, cookies, sesiones iniciadas y credenciales de terminal. La documentación pide expresamente que no uses bots separados como frontera de seguridad.

¿Grok Bot ve mis contraseñas?

No. Ante contraseñas, passkeys, códigos de dos factores, CAPTCHAs o confirmaciones de pago, el bot te devuelve el control para que escribas tú. Lo que no debes hacer es mandar una contraseña o un código por el chat normal.

¿Funciona en Linux?

No. Hay aplicación de escritorio para macOS y Windows, y app para iOS 18 o superior. Linux, Android e iPad no están soportados.

¿Qué plan hace falta?

SuperGrok Heavy, Cursor Ultra o Cursor Teams Premium. Cada uno incluye una cantidad de uso semanal y el consumo adicional se factura aparte. Para empresas hay lista de espera y precios a través del equipo comercial.

Fuentes

La documentación y el anuncio oficiales, que es de donde sale todo lo técnico de este artículo:

• Introducing Grok Bot, el anuncio.
• Grok Bot, Overview.
• Approvals, security, and privacy, de donde salen las citas sobre la frontera de seguridad y las aprobaciones.
• Use the computer and apps, sobre el ordenador compartido y los conectores.
• Preguntas frecuentes oficiales, sobre planes, plataformas y límites.