En este artículo
OpenBot: qué necesitan realmente los compañeros de IA autoalojados
Un compañero de IA necesita algo más que un navegador y un cargo
OpenBot es una plantilla de CopilotKit, con licencia MIT, para ejecutar compañeros de IA en infraestructura que tú controlas. Combina una interfaz de agentes, ordenadores con navegador, archivos, acceso a la terminal e integraciones MCP con una pasarela de políticas y auditoría en el servidor. Tú aportas el modelo y gestionas el despliegue.
Resulta interesante para equipos que necesitan más control del que ofrece un asistente empaquetado. Eso no lo convierte en un sustituto de Grok Bot listo para usar, completamente desconectado o seguro por defecto. El README actual de OpenBot lo describe expresamente como una plantilla en fase alfa, no como un producto terminado que otro mantiene por ti.
Nuestra recomendación: evaluar OpenBot en un proceso de negocio acotado y supervisado cuando la personalización de permisos y el control del despliegue sean requisitos reales. Que el código sea gratuito no basta para justificar la elección.
Método: evaluación documental de la versión v0.2.0 del 12 de octubre, revisada el 4 de noviembre de 2026. No hemos desplegado OpenBot ni realizado pruebas de penetración. La versión fijada es nuestra base de compatibilidad; no incluye automáticamente commits posteriores de main. Los criterios del piloto son pruebas propuestas, no resultados medidos.
¿Qué incluye OpenBot?
Una instalación nueva del ejemplo v0.2.0 empieza con General Assistant y Knowledge. Risk Analyst se registra al configurar su endpoint; otros diez ejemplos pasan a un catálogo no cargado. Los despliegues existentes conservan los compañeros registrados. Son roles configurables, no acreditación profesional ni autoridad para decidir.
Un compañero puede utilizar un navegador con sesiones conservadas, trabajar con archivos e invocar herramientas autorizadas. Google Drive y Notion aparecen en el catálogo MCP actual. La plataforma admite agentes que hablan AG-UI: puedes conectar un framework compatible o tu propio endpoint. OpenBot no es, en sí mismo, un modelo de lenguaje.
Crear un nombre, un puesto y unas instrucciones en la interfaz es la parte sencilla. El acceso al modelo, los endpoints, los permisos, las fuentes de datos y las pruebas de aceptación siguen necesitando un responsable. La documentación de despliegue también distingue qué agentes de ejemplo están disponibles cuando no se configura el endpoint de agente predeterminado.
¿Qué cambia al actualizar a OpenBot v0.2.0?
Las notas de v0.2.0 añaden cuentas Composio compartidas con comprobación de audiencia por Bot y aprobación humana para escrituras. “Always allow” en carpetas del escritorio cubre solo comandos de lectura; los que pueden editar o borrar preguntan cada vez. La página unificada Bots cambia la navegación, no la necesidad de conceder herramientas deliberadamente.
Haz una copia antes de 0052_shared_brokered_accounts: copia conexiones a brokered_connections y deja de escribir en la tabla anterior. Volver a v0.1.2 oculta las cuentas conectadas después de actualizar. Los runs remotos firmados anteriores pueden recibir rechazos de apps Shared durante hasta diez minutos por carecer del nuevo registro de iniciador. Prueba estas transiciones antes de actualizar una rutina activa.
La arquitectura fijada también documenta un proxy de salida. Bloquea destinos de metadatos cloud, pero un proceso con sockets directos puede saltarse el proxy. Impón las fronteras de red estrictas fuera del proceso, por ejemplo mediante Kubernetes NetworkPolicy: configurar un proxy no equivale a aislamiento completo.
El diseño importante: política, auditoría y después ejecución
La documentación de arquitectura de OpenBot sitúa el control de acciones en el servidor, no en las instrucciones del modelo. Para las acciones de ordenador que pasan por esta ruta, la pasarela identifica el destino, evalúa la política, registra la decisión y solo entonces reenvía una acción permitida. Los fallos de ejecución generan un registro adicional.
Solicitud del agente → resolver destino → evaluar política → registrar decisión → ejecutar o rechazar
Es un control más sólido que pedirle al modelo que tenga cuidado. Un revisor puede comprobar qué regla permitió o denegó una acción, sin depender de la explicación posterior del asistente.
Sin embargo, registrar una autorización no demuestra que el resultado de negocio sea correcto. Tampoco convierte una escritura externa en atómica, reversible o segura ante cualquier reintento. Crear dos veces un proveedor sigue siendo un error aunque ambas solicitudes estén registradas. Esas propiedades requieren un diseño propio del proceso.
El límite cubre las acciones encaminadas por la plataforma. No debe interpretarse como una garantía de que código arbitrario o un endpoint de agente operado por separado nunca puedan actuar fuera de esa ruta.
¿OpenBot deniega todo por defecto?
El evaluador deniega cuando falta una autorización, pero la política de arranque incluida es permisiva. Son dos hechos distintos.
La arquitectura establece que una política ausente o vacía no permite nada; las denegaciones tienen prioridad; una expresión de denegación defectuosa bloquea; una expresión de permiso defectuosa no autoriza. También indica que el arranque proporciona una política explícita con deny: [] y allow: ["true"], salvo que una variable de entorno o una política guardada por el administrador la sustituya.
Por tanto, «sin política no se permite nada» no significa que una instalación nueva tenga una política empresarial restrictiva. Antes de conectar cuentas corporativas, sustituye la configuración permisiva por autorizaciones revisadas y comprueba resultados permitidos y rechazados.
OpenBot utiliza Common Expression Language (CEL) para expresar las reglas. CEL es un lenguaje de expresiones integrado, no una petición a otro modelo. Permite inspeccionar y probar reglas frente al contexto de una acción. Su calidad sigue dependiendo de los campos que aporte la aplicación y de las condiciones que escriba tu equipo.
Para separar conectividad y autorización, consulta por qué MCP no es el límite de seguridad.
¿Está aislado cada compañero de IA?
El aislamiento depende de la arquitectura que realmente despliegues. Con el supervisor configurado, cada Bot recibe su propio contenedor de ordenador, volumen de trabajo y perfil de Chromium. Sin él, los Bots pueden compartir el ordenador configurado.
Esto importa porque la guía de despliegue actual de OpenBot también ofrece una imagen de un solo contenedor que no incluye el supervisor. En esa modalidad, los Bots comparten navegador, archivos y sesiones. La guía advierte expresamente que ese entorno compartido no sirve como frontera entre clientes o inquilinos distintos.
Antes de aprobar un despliegue, pregunta qué arquitectura está funcionando. Que el README mencione contenedores no es suficiente. Un nombre de Bot diferente no crea aislamiento. Un contenedor separado tampoco restringe automáticamente los destinos de red o las cuentas externas disponibles dentro de él.
Es un modelo distinto al entorno desechable por sesión de programación de Ramp Inspect. Los perfiles y espacios de trabajo persistentes de OpenBot necesitan procedimientos propios de retención, reinicio y revocación de cuentas. Para una plataforma de ejecución aislada en lugar de una aplicación completa de compañeros, compara OpenSandbox.
¿Qué ocurre al iniciar sesión o completar la autenticación de dos factores?
OpenBot documenta una toma de control humana en el mismo panel del navegador. La persona completa el inicio de sesión u otro paso que necesita atención y después devuelve el control. Mientras conduce la persona, las acciones del Bot sobre el navegador se rechazan en vez de quedar en cola.
Es una regla útil: evita acumular acciones mientras alguien cambia la página o introduce credenciales. No equivale a autorizar todo lo que el Bot haga al recuperar el control.
La entrada específica de secretos está separada del chat y sus eventos de auditoría registran metadatos, no el valor del secreto. Aun así, trata los perfiles del navegador, las sesiones autenticadas, las capturas y las salidas de herramientas como información sensible. Proteger la introducción de una contraseña no vuelve inocuas todas las observaciones posteriores.
Utiliza una cuenta limitada a la tarea y verifica que cerrar sesión o revocar acceso tenga efecto. Completar la autenticación de dos factores demuestra que una persona se autenticó. No autoriza al compañero a enviar mensajes, aceptar condiciones o aprobar compras.
¿OpenBot es completamente autoalojado o completamente local?
Puedes alojar OpenBot, pero debes considerar toda la ruta de datos. La referencia actual de configuración exige parámetros de conexión a CopilotKit Intelligence. También admite endpoints de modelo compatibles, que pueden corresponder a una API de proveedor, una pasarela o infraestructura propia.
| Capa | Ubicación en el diseño documentado | Decisión necesaria |
|---|---|---|
| Datos del producto y auditoría | Tu PostgreSQL | Copias, acceso, retención y recuperación |
| Sesiones del navegador y archivos | Ordenador configurado y volúmenes persistentes | Aislamiento, reinicio, revocación y cifrado |
| Conversaciones y memoria | CopilotKit Intelligence | Servicio gestionado o autoalojado, retención y condiciones |
| Peticiones de inferencia | Endpoint del modelo elegido | Qué contexto sale del entorno y cómo se trata |
| Drive, Notion y otras herramientas | Servicios conectados y resultados devueltos | Identidad del usuario, permisos del destino y exposición de datos |
Un modelo local cambia la capa de inferencia. No traslada por sí solo la persistencia de conversaciones ni los servicios empresariales conectados a tu ordenador.
La configuración actual de Intelligence gestionado utiliza la clave de ejecución del proyecto sin un token de licencia adicional. Una instalación autoalojada puede necesitar su propia configuración de derechos. Sigue la documentación fijada a la versión, no los comandos de un tutorial antiguo.
Si necesitas un plano de control multiusuario más amplio en lugar de una plantilla centrada en el navegador, nuestro análisis de Tencent Octop examina su licencia MIT, arquitectura de un solo proceso, límite de dependencias y costes operativos.
¿Qué cuesta OpenBot además de los tokens?
La licencia MIT cubre el código de OpenBot. También debes presupuestar cómputo, PostgreSQL, almacenamiento, copias, uso del modelo, la modalidad de Intelligence, mantenimiento de conectores y operación.
A 4 de noviembre de 2026, los precios de CopilotKit asignan al plan Developer gratuito un desarrollador, 200 conversaciones y tres días de retención. El autoalojamiento incluido cubre solo el entorno de ejecución. Confirma persistencia y condiciones: gratuito no significa ilimitado ni completamente local.
Una medida útil es:
Coste por tarea aceptada = (modelo + alojamiento + persistencia + operación + revisión + correcciones) ÷ tareas aceptadas
Vincula el denominador a un resultado acordado. Una factura de tokens baja no supone ahorro si el personal repite el trabajo o reconstruye evidencias perdidas. Las fuentes públicas revisadas no demuestran una ventaja de coste para tu proceso concreto.
OpenBot frente a Grok Bot: responsabilidad operativa, no equivalencia supuesta
OpenBot como alternativa a Grok Bot es una opción de compra, no una equivalencia comprobada. La documentación oficial de Grok Bot describe ordenadores gestionados, aislamiento Firecracker por usuario, ordenador compartido entre sus Bots y aprobaciones. Las funciones administrativas dependen del plan.
| Decisión | OpenBot | Grok Bot gestionado |
|---|---|---|
| Responsable del funcionamiento | Tú mantienes la aplicación clonada y su despliegue | El proveedor opera el producto |
| Personalización | Código fuente, agentes compatibles y política CEL propia | Funciones y controles ofrecidos por el servicio |
| Pregunta de aislamiento | Ordenador por Bot con supervisor; posible alternativa compartida | Frontera de cómputo documentada por usuario |
| Pregunta de compra | ¿La personalización justifica desarrollo y mantenimiento? | ¿Encajan las funciones y las condiciones? |
Ninguna opción es automáticamente más segura o barata. Para un proceso habitual, un producto mantenido puede ser la mejor decisión. La guía de software a medida frente a soluciones estándar explica cuándo compensa asumir el coste de la propiedad.
Un piloto práctico de OpenBot para una empresa
Empieza por preparar documentos, no por hacer pagos o administrar producción. Un ejemplo ilustrativo es un informe de alta de proveedor: recuperar documentos permitidos, señalar evidencias faltantes y producir un borrador para aprobación humana. El compañero no debe activar al proveedor, enviar el informe fuera de la empresa ni aprobar una factura.
El diseño de controles debe seguir la orientación de OWASP sobre exceso de capacidad de actuación: minimizar funciones, permisos y autonomía, imponer la autorización en los sistemas utilizados y exigir aprobación para acciones importantes.
Días 1–3: delimitar el trabajo. Elige responsable, proceso, conjunto fijo de tareas y resultados esperados. Usa documentos sintéticos o aprobados para pruebas. Registra revisión de OpenBot, modelo y arquitectura. Sustituye la política permisiva y configura autenticación antes de permitir el acceso de otras personas.
Días 4–7: comprobar controles. Las lecturas legítimas deben funcionar y las escrituras prohibidas deben rechazarse. Verifica que el sistema se detenga en lugar de actuar sin su registro de auditoría obligatorio. Prueba la toma de control del navegador y su devolución, y comprueba la separación de cuentas y archivos en la modalidad seleccionada.
Días 8–10: comprobar operación. Reinicia el despliegue, recupera la base de auditoría, revisa qué conserva realmente la retención de conversaciones y revoca una cuenta conectada. Prueba una llamada fallida y una solicitud repetida sin permitir cambios de negocio duplicados. Documenta la recuperación en lugar de confiar en el estado saludable de un contenedor.
Días 11–14: comparar resultados. Mide finalización, tiempo del revisor, correcciones, gasto del modelo y esfuerzo operativo frente al proceso actual. Amplía solo cuando la calidad se mantenga, los permisos funcionen y mejore el esfuerzo total. En caso contrario, reduce el encargo, utiliza una integración determinista o compra una herramienta gestionada.
¿Cuándo elegir OpenBot?
Un piloto controlado tiene sentido con responsable técnico, proceso concreto y un motivo real para personalizar despliegue, agentes o política. Aplázalo si necesitas sobre todo un asistente con soporte y poco mantenimiento, o nadie puede asumir autenticación, permisos y recuperación.
La consultoría de IA de Wavect ayuda a resolver esa decisión antes de construir una plataforma. Un primer entregable útil es un mapa de datos, una matriz de permisos, tareas representativas y una recomendación justificada para continuar o detenerse. El caso de Twinsoft AI ilustra nuestro trabajo para hacer aplicaciones de IA mantenibles y preparadas para uso real; no implica que hayamos desplegado OpenBot allí.
Consulta un piloto de viabilidad de OpenBot centrado en un proceso y sus criterios de aceptación, en vez de empezar con una implantación en toda la empresa.
La oportunidad no consiste simplemente en dar más acceso a compañeros de IA. Consiste en hacer explícito y observable el acceso concedido, y justificar su coste operativo. OpenBot aporta un punto de partida para ese trabajo, no lo sustituye.