OpenBot, el lanzamiento de CopilotKit del 19 de agosto de 2026, plantea una pregunta que la mayoría de las herramientas de agentes evitan: si un bot de IA comete un error o se compromete, ¿qué radio de daño tiene exactamente?
La respuesta de OpenBot es arquitectónica y explícita: cada bot tiene su propio ordenador, con su propio navegador, sus propias sesiones y sus propios ficheros, separados de los demás. Un bot no puede leer los ficheros de otro ni reutilizar sus sesiones. Por el contrario, Grok Bot de xAI adopta el diseño opuesto: compartir un ordenador persistente en la nube entre todos los bots, con un aislamiento por usuario y no por bot. No son soluciones equivalentes que se puedan intercambiar sin consecuencias. Son decisiones de diseño distintas con consecuencias distintas en quién paga cuando algo sale mal.
Este artículo no repasa qué es OpenBot ni cómo se instala, porque eso ya está en qué es CopilotKit OpenBot, donde cubrimos la arquitectura, la instalación paso a paso, el protocolo AG-UI y la comparativa general con alternativas. Aquí nos centramos en lo que empecé a querer entender cuando empecé a programar y vi agentes por primera vez en un equipo real: por qué el aislamiento importa en una empresa, cómo se decide qué puede hacer cada bot, y qué registros te permiten demostrarlo si un auditor te pregunta.
¿Por qué el aislamiento importa en un agente de IA cuando ya tienes contraseñas y permisos?
La gente que empieza a programar suele pensar en seguridad como en un muro: un login, un firewall, una contraseña fuerte. Con los agentes de IA la cosa es más fea, porque un agente no es una cuenta de usuario que entras y sales. Es un proceso que puede actuar por ti, con tus credenciales o con acceso a tus herramientas, y que puede estar ejecutándose mientras tú no estás mirando.
Imagina que en tu empresa creas tres bots: uno para responder preguntas del conocimiento interno, otro para revisar métricas de ventas, y otro para gestionar la ingesta de documentos desde un formulario público. Si los tres comparten el mismo navegador, las mismas sesiones y los mismos ficheros, una vulnerabilidad, un prompt malicioso o un comportamiento inesperado en el bot de ingesta puede mover el contexto del bot de métricas o leer lo que el bot de conocimiento tenía almacenado. No porque haya una cuenta compartida mal gestionada, sino porque hay un recurso compartido que ninguno de los tres podía aislar del resto.
El aislamiento no es solo un problema de seguridad al invasions. También es un problema de responsabilidad interna. Si algo sale mal, quieres saber qué bot lo hizo, en qué contexto, con qué permisos, y en qué momento. Si los bots comparten estado, esa pregunta se vuelve mucho más difícil de responder, porque el rastro se mezcla.
Por eso el diseño de OpenBot apunta directo a esto: aislar cada bot en su propio ordenador, con su propio navegador, sus propias sesiones y sus propios ficheros. Según lo que ha dicho su propio autor, Atai Barkai, en el hilo de lanzamiento del 19 de agosto de 2026, cada Bot tiene su propio ordenador, con navegador, sesiones y ficheros separados, y un Bot no puede leer los ficheros de otro ni reutilizar sus sesiones. Esa frase importa porque es una decisión de diseño, no una mejora de marketing sobre una arquitectura ya existente.
¿Cuál es la diferencia real entre aislamiento por bot y aislamiento por usuario?
Aquí es donde la comparación se vuelve útil y, al mismo tiempo, hay que ser cuidadoso con no convertirla en una batalla de bandos.
OpenBot aísla por bot. Cada bot tiene su propio entorno de ejecución. Si un bot se compromete o se comporta mal, el radio de daño se limita a lo que ese bot tenía permiso de tocar en su propio ordenador. No hay un ordenador compartido donde un solo fallo pueda mojar a todos.
Grok Bot adopta un diseño distinto. Su FAQ oficial dice literalmente que cada Grok Bot comparte un ordenador persistente en la nube, y que el aislamiento es por usuario y no por Grok Bot. Es decir: en el modelo de Grok Bot, el radio de daño de un bot comprometido puede ser la cuenta entera, porque hay un recurso compartido por encima del nivel del bot. No es que Grok Bot sea inseguro por definición, ni que OpenBot sea automáticamente más seguro. Son modelos distintos con compensaciones distintas.
La compensación de OpenBot es mayor granularidad y mayor trazabilidad, pero también mayor complejidad operativa. La compensación de Grok Bot es que hay menos fronteras entre bots, lo que puede simplificar algunas cosas, pero cambia la pregunta de seguridad: no estás preguntando qué puede hacer un bot concreto en su propio ordenador, estás preguntando qué puede hacer un bot dentro de una cuenta donde los demás bots también viven.
Para una empresa, la pregunta no es cuál es más elegante en paper. Es cuál se ajusta a tu modelo de responsabilidad. Si tienes equipos distintos con datos distintos, y quieres que un problema en un flujo no pueda extenderse por culpa de un recurso compartido, el aislamiento por bot es la abstracción que encaja mejor. Si tu caso es más cercano a un usuario que tiene varios bots como extensiones de sí mismo, sin datos cruzados sensibles entre ellos, el modelo compartido puede tener sentido.
El punto que sí conviene tener claro es el siguiente: no es lo mismo aislamiento por usuario que aislamiento por bot. Y si un auditor, un cliente o una regulación te pregunta por dónde está la frontera cuando un bot falla, la respuesta de tu arquitectura importa.
¿Qué significa gobernar un agente en una empresa, más allá de si puede o no puede hacer algo?
Cuando se habla de gobernanza de agentes, a veces el discurso se queda en listas genéricas de controles. En la práctica, gobernar un agente en una empresa suele significar poder responder a tres preguntas cuando algo necesita justificarse: qué pasó, quién lo resolvió o lo permitió, y por qué.
OpenBot registra no solo qué pasó, sino quién tomó la decisión y por qué. Esa es una diferencia sustantiva frente a sistemas que solo dejan un registro de acciones o de salidas del modelo. En un entorno empresarial, eso no es un detalle. Es lo que te permite diferenciar un error operativo de una acción autorizada, y lo que te permite defender una decisión ante alguien que no estaba en la sala cuando se tomó.
Piensa en un escenario concreto y realizable: un bot de análisis de riesgos está configurado para consultar un origen de datos interno y genera un resumen que va a un canal de equipo. Si más tarde alguien pregunta por qué cierto número salió en el resumen, o por qué se consultó un origen y no otro, no basta con un log genérico. Necesitas saber qué regla aplicó el gateway, qué actor humano o automático lo autorizó, y en qué momento. Eso es lo que te permite pasar de "el bot dijo esto" a "esto fue permitido bajo estas condiciones, por este motivo, en este momento".
Esa capa de gobernanza es especialmente relevante cuando los agentes no están limitados a responder preguntas, sino que pueden actuar sobre sistemas reales: navegar, rellenar formularios, usar herramientas, tocar datos. Cuando un agente tiene capacidad de acción, la pregunta de auditoría cambia de "qué dijo" a "qué hizo y por qué se permitió".
¿Cómo funciona el aislamiento en la práctica con OpenBot?
En el diseño de OpenBot, el aislamiento no es un añadido al final, sino parte de la forma en que vive cada bot. Cada Bot tiene su propio ordenador, con navegador, sesiones y ficheros separados. Eso significa que las fronteras son explícitas desde el arranque, no una capa de permisos que se aplica después.
Hay una diferencia importante entre decir "tenemos permisos bien gestionados" y decir "este bot no comparte ningún recurso de ejecución con ese otro". Los permisos pueden ser correctos y, incluso así, un fallo en un nivel compartido puede generar fuga de contexto o contaminar sesiones. El aislamiento por ordenador separado es más estricto porque reduce la superficie compartida antes de llegar a los permisos.
Esto no significa que OpenBot elimina todos los problemas. Significa que la frontera de mayor nivel está trazada de forma que un bot no lee los ficheros de otro y no reutiliza sus sesiones. El resto, como los permisos sobre las herramientas, los fuentes de datos a las que puede acceder, y las acciones que puede ejecutar, sigue siendo algo que administra quien configura el sistema.
Un detalle que puede pasar desapercibido a primera vista y que en realidad importa en empresas: la memoria y los hilos van atados a la persona, no al navegador. Y los datos nuevos sustituyen a los viejos en vez de acumularse. Eso es distinto de un modelo donde todo se va apilando sin gestión de caducidad. En un entorno de workspace, esa elección afecta tanto a la privacidad como a la consistencia del contexto que el agente ve.
¿Qué han dicho otros sobre el aislamiento y los límites de este modelo?
No todo el mundo está de acuerdo con que el aislamiento actual de OpenBot sea suficiente. Tobi Lütke, CEO de Shopify, respondió al hilo de lanzamiento diciendo que le falta bash y un gestor de paquetes, y sugirió gVisor como sandbox.
Esa pega es real y merece ser contada tal cual, sin elogios ni disculpas. gVisor es un sandbox de contenedores que añade una capa extra de aislamiento entre el proceso y el kernel del host. Si lo que buscas es una frontera de ejecución más estricta, gVisor entra en el juego. La sugerencia de Lütke señala un punto legítimo: incluso cuando un diseño aísla por bot, hay quien quiere una capa más de contención por debajo, especialmente en entornos donde el nivel de confianza no es alto.
No tiene sentido ocultar esa crítica ni presentarla como algo menor. Si vas a evaluar OpenBot para un equipo real, conviene que tengas presente que otros actores del sector están señalando límites concretos, no solo elogiando el concepto. Al mismo tiempo, tampoco hay que exagerarlo: es un proyecto en alpha, y las críticas técnicas sobre qué falta o qué capa extra merece la pena añadir son parte normal de cómo maduran estos sistemas.
¿Qué frameworks puede usar OpenBot y por qué importa eso en una empresa?
OpenBot funciona con cualquier agente que hable AG-UI: Google ADK, AWS Strands, Microsoft Agent Framework, LangChain, CrewAI, Mastra, Pydantic AI y Claude Agent SDK. Va sobre el Channels SDK, que es la capa recién publicada que permite que esos agentes lleguen como coworkers con canal propio.
Esto importa en una empresa porque no estás atado a comprar un agente nuevo para entrar en un modelo de workspace. Si ya tienes agentes hechos con alguna de esas opciones, puedes añadirlos sin cambiar de harness subyacente y darles identidad, canal y las fronteras que OpenBot maneja. Para equipos que ya han invertido en construir agentes con LangChain, CrewAI o cualquiera de esas opciones, eso puede ser la diferencia entre un proyecto que se queda como demo y uno que llega a un flujo de trabajo real.
La otra cara de la moneda es que la gobernanza y el aislamiento se aplican sobre la capa de protocolo, no sobre una tecnología concreta de agente. Eso puede simplificar la vida a la hora de mantener el control sin estar atado a un framework en particular. Pero también significa que, si quieres aprovechar esto en un equipo real, necesitas entender qué es AG-UI, qué es el Channels SDK, y cómo encaja tu agente actual en esa capa.
¿Para quién tiene sentido este diseño y para quién no?
El diseño de OpenBot tiene sentido para una empresa que necesita que cada bot tenga fronteras claras, que quiere trazabilidad de decisiones, y que prefiere ejecutar la plataforma en su propia infraestructura en lugar de ceder el sistema a un SaaS de tercero. Eso incluye equipos que trabajan con datos sensibles, equipos que necesitan demostrar controles, y equipos que ya tienen agentes construidos con distintos frameworks y quieren darles un canal y un aislamiento explícito.
No tiene sentido como solución mágica para cualquiera. Si buscas algo que prefabricado, sin operar contenedores, sin gestionar claves, y con una experiencia estilo producto listo para usar, este tipo de plataforma no entra en ese perfil. Tampoco tiene sentido si tu necesidad real es simplemente tener un bot que responda preguntas sin acción sobre sistemas internos, porque entonces el problema de aislamiento que estamos leyendo no es el tuyo.
Y en todo caso, hay que recordar que OpenBot está en alpha. Lo dice su propio autor en el hilo de lanzamiento. Esto significa que el proyecto está en desarrollo activo, con aristas sin pulir y decisiones que pueden cambiar. No es un momento para recomendarlo para producción sin avisar de eso. Más bien es el momento para entender qué tipo de compromisos arquitectónicos está haciendo y decidir si encajan con tu caso antes de que madure.
¿Por qué este tema importa si estás aprendiendo a programar y no dirigiendo un equipo enterprise?
Porque la forma en que piensas sobre aislamiento y responsabilidad hoy es la misma forma en que vas a tener que pensar cuando construyas agentes reales. No es un tema puramente de role executive. Si empiezas a programar y tu primer contacto con los agentes es un chatbot que responda preguntas, puedes salir de ahí pensando que la seguridad es algo que "alguien de infra" resuelve después. Pero cuando un agente puede actuar sobre sistemas, leer datos, navegar, o interactuar con otras herramientas, el tema de qué está aislado de qué, qué registra, y quién autoriza pasa a ser un problema de ingeniería, no de política.
Las consecuencias reales no son hipotéticas. Una mala frontera entre bots puede amplificar el radio de daño de un fallo. Un sistema sin registro claro de decisiones puede dejarte sin explicación cuando alguien pregunta por qué hizo algo. Y una elección de diseño como compartir un recurso persistente entre bots puede tener sentido en algunos casos, pero conlleva una responsabilidad distinta que hay que entender antes de adoptarlo.
Entender esto no requiere ser experto en seguridad. Requiere entender que un agente no es solo un modelo que genera texto, y que el aislamiento no es solo un firewall. Requiere entender que, en una empresa, los problemas más costosos no suelen ser los que el modelo dió por mal, sino los que nacieron de recursos compartidos mal trazados y decisiones no registradas.
Preguntas frecuentes
¿Qué significa que OpenBot aísla por bot y no por usuario? Significa que cada bot tiene su propio ordenador con navegador, sesiones y ficheros separados, y que un bot no puede leer los ficheros de otro ni reutilizar sus sesiones. Grok Bot, por el contrario, comparte un ordenador persistente en la nube y aísla por usuario, no por bot.
¿Es OpenBot más seguro que Grok Bot? No se puede afirmar eso de forma absoluta. Son decisiones de diseño distintas. OpenBot traza una frontera más estricta entre bots; Grok Bot comparte un recurso persistente por encima del nivel del bot. Lo que cambia es el radio de daño y la forma en que se comporta un problema si uno de los bots falla o se compromete.
¿Qué significa que OpenBot registra quién tomó la decisión y por qué? Significa que el registro no se limita a qué acción ocurrió, sino que también apunta quién la autorizó o resolvió y el motivo asociado. Eso es relevante para auditoría y para poder explicar una decisión en un entorno empresarial.
¿Puedo usar mis agentes actuales con OpenBot? Sí, si hablan AG-UI. OpenBot funciona con Google ADK, AWS Strands, Microsoft Agent Framework, LangChain, CrewAI, Mastra, Pydantic AI y Claude Agent SDK, sobre el Channels SDK.
¿Está OpenBot preparado para producción en agosto de 2026? No, está en alpha. El propio autor lo indica en el hilo de lanzamiento. Conviene usarlo como proyecto de evaluación o piloto interno, no como base de producción sin avisar de su estado.
¿Qué críticas reales ha recibido el lanzamiento? Tobi Lütke, CEO de Shopify, respondió al hilo diciendo que le falta bash y gestor de paquetes, y sugirió gVisor como sandbox. Es una crítica técnica pública y relevante, no una opinión genérica.
Fuentes verificadas: hilo de lanzamiento de CopilotKit y de Atai Barkai (@ataiiam) del 19 de agosto de 2026; landing oficial en https://www.copilotkit.ai/openbot; repositorio https://github.com/CopilotKit/openbot; FAQ oficial de Grok Bot con la frase sobre compartir un ordenador persistente en la nube y aislamiento por usuario; crítica pública de Tobi Lütke en el mismo hilo de lanzamiento. El artículo de referencia de 4Geeks sobre qué es CopilotKit OpenBot está en https://4geeks.com/es/blog/herramientas-ia/que-es-copilotkit-openbot.