Una computadora por cada bot: qué propone OpenBot y qué no resuelve todavía

Una empresa que ya trae dos o tres agentes trabajando llega tarde o temprano al mismo punto. Uno responde correos de clientes, otro concilia facturas, otro prepara reportes. Cada uno se configuró por su lado, todos usan la misma cuenta de correo o el mismo usuario del ERP, y nadie sabe decir con exactitud qué hizo cada uno la semana pasada ni con qué permisos.

Ese no es un problema de inteligencia artificial. Es un problema de gobierno: separación de funciones, credenciales, bitácora y autorización previa. Lo mismo que se le exige a cualquier persona con acceso al sistema de la empresa, y que a los agentes se les suele perdonar porque el asunto todavía se ve como un experimento.

El 19 de agosto de 2026 CopilotKit publicó OpenBot, un proyecto de código abierto con licencia MIT que ataca exactamente ese punto. Vale la pena revisarlo, y vale la pena revisarlo con calma, porque está en alfa y sus propios autores lo dicen en la primera pantalla.

Cómo se resuelve hoy esto en la práctica

En la mayoría de las empresas que ya tienen agentes en operación, la separación entre ellos es de palabra. Los agentes corren en la misma máquina o en el mismo servicio, comparten un archivo de configuración con las llaves adentro, y el control sobre lo que pueden hacer es el que trae el proveedor del modelo, que es genérico.

La bitácora, cuando existe, es el historial de conversación. Sirve para leer qué se dijo, no para responder la pregunta que interesa en una auditoría: qué herramienta se ejecutó, con qué parámetros, contra qué sistema y bajo qué autorización.

La alternativa que se usa cuando el asunto se pone serio es dar de alta a cada agente como si fuera un empleado: su usuario en el ERP, sus permisos, su registro. Funciona, y es trabajo manual que hay que rehacer con cada agente nuevo.

Qué propone OpenBot

La idea central es que cada bot recibe su propia computadora. No es una metáfora: cada uno corre en un contenedor con su carpeta de trabajo, su perfil de navegador y sus credenciales. El bot de ventas no alcanza los archivos ni las sesiones del bot de contabilidad, salvo que se comuniquen explícitamente entre ellos.

Encima de eso hay una compuerta por la que pasa toda acción antes de ejecutarse. El flujo declarado es resolución, evaluación de política, registro de auditoría y ejecución o rechazo. Las reglas se escriben en CEL, un lenguaje de expresiones, y pueden inspeccionar el nombre de la herramienta, el bot que la invoca, la dirección de la página en la que está o el elemento que va a tocar.

Tres detalles del diseño de esas reglas merecen atención, porque son los que distinguen una compuerta seria de una casilla de verificación. El rechazo se evalúa antes que el permiso. La ausencia de política no permite nada. Y una regla rota rechaza en lugar de abrir. Cada rechazo deja registrada la regla concreta que lo provocó.

Las credenciales se guardan cifradas, no las devuelve la interfaz de programación y se omiten de los eventos de auditoría. Las de identidad se almacenan como solo escritura.

El paquete trae tres bots configurados de ejemplo —un asistente general, uno de conocimiento y un analista de riesgo— y se definen como configuración, no como código: se agregan editando un archivo o desde la interfaz.

Qué no resuelve, y esto es lo que no cuentan los videos

Primero, el aislamiento por omisión es el de un contenedor de Docker. Eso separa bien el trabajo de un bot del de otro, que es el problema de gobierno que se quería atacar. No es lo mismo que una frontera de seguridad frente a algo que se empeñe en salirse. El proyecto contempla correr las computadoras bajo gVisor, que sí endurece esa frontera, pero es una opción que hay que activar, no lo que viene puesto.

Segundo, hay una dependencia externa en medio de la capa de gobierno: se requiere un proyecto y una licencia de CopilotKit Intelligence, con plan gratuito disponible. Conviene entenderlo antes de decidir, porque es la pieza que se supone que da el control.

Tercero, y es un detalle de operación que cuesta caro si se descubre tarde: las computadoras de cada bot pertenecen al supervisor y no a Docker Compose. Bajar el conjunto con la instrucción habitual de borrado no las elimina. Los contenedores siguen corriendo y los volúmenes con los perfiles sobreviven. En una máquina compartida eso se traduce en procesos y disco ocupados que nadie está contando.

Cuarto, el consumo de tokens lo paga la empresa y la herramienta no lo limita. Que cada acción pase por una compuerta agrega llamadas, no las quita.

Y quinto: alfa. Los autores escriben que hay que esperar aristas, errores y cambios. Eso descarta ponerlo debajo de un proceso que no pueda pararse.

Costo y requisitos antes de empezar

Lo que hace falta tener es concreto: Docker, Bun en su versión 1.3 o superior, PostgreSQL —que se levanta con el propio Docker—, una llave de modelo de OpenAI, Anthropic o Google, y el proyecto de CopilotKit Intelligence.

El gasto se reparte en tres partidas. La licencia, que en el plan gratuito es cero. Los tokens del modelo, que dependen del volumen y son la partida que crece. Y la infraestructura, que es la que casi nadie estima: un contenedor por bot con navegador adentro no es ligero, y el número de bots multiplica memoria y disco directamente.

Una prueba honesta cuesta poco: dos bots, una semana, un proceso que ya se esté haciendo a mano y que no sea crítico.

Cómo saber si funcionó

Tres preguntas, y ninguna se responde mirando la demostración.

¿Se puede reconstruir, sin abrir una conversación, qué hizo cada bot ayer? Si la respuesta está en la bitácora de auditoría y no en el historial del chat, la herramienta está cumpliendo su función.

¿Cuántas acciones se rechazaron y por qué regla? Cero rechazos en una semana no significa que todo salió bien: significa que las políticas están abiertas.

¿Cuánto costó en tokens la semana con compuerta comparada con la semana sin ella? Es el precio del control, y conviene conocerlo antes de decidir si se paga.