Cómo ejecutar agentes de IA en local (guía 2026)

Ejecutar un agente de IA en local significa que el proceso de orquestación y los archivos de trabajo están en tu ordenador. No significa necesariamente que el modelo se ejecute en local ni que todos los datos se queden en la máquina. Un modelo en la nube recibe los prompts y los adjuntos que se le envían, mientras que los navegadores, Telegram y otras herramientas se conectan a sus propios servicios.

Puedes usar una aplicación de escritorio nativa como noHuman Team en macOS o Windows, montar una configuración en contenedores o conectar un servidor de modelos local. La opción adecuada depende del aislamiento que necesites, de los proveedores y del mantenimiento que quieras asumir.

¿Qué significa «ejecutar agentes de IA en local»?

Una configuración local puede mantener estos componentes en tu ordenador:

• Procesos de agentes y orquestación
• Configuración e instrucciones de rol
• Archivos de trabajo y memoria
• Perfiles de navegador
• Registros y estado de las aprobaciones

El modelo puede seguir ejecutándose en Anthropic, OpenAI, Google u otro proveedor configurado. Si conectas un servidor de modelos local, la inferencia también puede quedarse en hardware bajo tu control, según las capacidades de ese modelo y de ese servidor.

No tomes «local» como garantía de privacidad. Haz una lista de los destinos reales que usa el flujo de trabajo.

¿Por qué ejecutar agentes en tu propio ordenador?

Acceso directo a la carpeta de trabajo que elijas

Un proceso local puede trabajar con la carpeta que elijas sin subir todo la carpeta de trabajo a una plataforma de agentes alojada. Los archivos que se incluyen en los prompts del modelo o en llamadas a herramientas externas sí salen de la máquina, así que acota la carpeta de trabajo y revisa las integraciones.

Control de la configuración y del estado

Puedes guardar las instrucciones de rol, la memoria de trabajo y los registros en archivos bajo tu control. La portabilidad sigue dependiendo de su formato y de las funciones específicas de cada proveedor que use el flujo de trabajo.

Libertad para elegir proveedor

Un orquestador local puede admitir motores que funcionan con suscripción, proveedores con clave de API o un endpoint de modelo local. La disponibilidad de modelos depende del acceso al proveedor y de la versión del motor instalada.

Procesos locales observables

Funcionar en local facilita revisar los procesos, los archivos y el uso de recursos. No hace que un agente acierte, sea inofensivo ni cumpla la normativa de forma automática.

Dos arquitecturas habituales

Agentes de escritorio nativos

Una aplicación nativa lanza los procesos de los agentes directamente en macOS o Windows. Así no hace falta Docker, y se pueden ofrecer ventanas de navegador visibles y una integración directa con el escritorio.

La contrapartida es importante: un agente nativo suele ejecutarse con los permisos de la cuenta de usuario, salvo que se aplique además un sandbox del sistema operativo. Elegir una carpeta de trabajo marca un límite organizativo, no un límite del sistema de archivos que el kernel imponga automáticamente.

noHuman Team usa procesos nativos supervisados, estado de trabajo y perfiles de navegador separados, una pasarela de credenciales local, controles de aprobación y límites por agente. No promete el aislamiento de un contenedor.

Agentes en contenedores

Una configuración con Docker empaqueta un agente y sus dependencias en un contenedor. Los espacios de nombres restringen lo que ve de los procesos, los sistemas de archivos y las redes; los controles de recursos pueden limitar la CPU y la memoria si se configuran.

El acceso de un contenedor al host depende de la configuración. Los montajes bind exponen rutas del host, el socket de Docker puede dar un amplio control del daemon, y el modo privilegiado, los dispositivos, las capacidades, los secretos o una red permisiva pueden debilitar el aislamiento.

Revisa la guía de aislamiento con Docker antes de confiar en un contenedor como control de seguridad.

Qué necesitas

Los requisitos cambian según la opción.

Opción nativa con noHuman Team

• Un ordenador compatible, con macOS o Windows
• Un motor compatible que funcione con suscripción, o un proveedor con clave de API
• Una carpeta de trabajo que no te importe exponer a los noHumans configurados
• Cuentas opcionales de Telegram y de navegador, preferiblemente dedicadas y con los mínimos privilegios

Opción por tu cuenta con contenedores

• Una instalación de Docker compatible
• Un framework o runtime de agentes que puedas mantener
• Acceso a un modelo mediante una API o un servidor local compatible
• Un plan explícito para montajes, secretos, redes, límites, registros y actualizaciones

Las necesidades de hardware dependen de cuántos agentes se ejecutan a la vez, de los navegadores, de las herramientas locales y de si la inferencia del modelo se ejecuta en la máquina. Consulta los requisitos actuales del producto o del framework en lugar de fiarte de una cifra genérica de RAM.

Cómo configurar noHuman Team en local

1. Elige un instalador disponible para tu sistema operativo en nohuman.team/install.
2. Abre la aplicación y sigue los pasos de configuración del motor.
3. Conecta una suscripción compatible o un proveedor con clave de API.
4. Elige o crea un equipo y asigna modelos que admitan el proveedor conectado y el motor instalado.
5. Selecciona la carpeta de trabajo y revisa los permisos y los ajustes de autonomía de cada noHuman.
6. Añade cuentas de Telegram o de navegador solo si el flujo de trabajo las necesita.
7. Lanza una tarea pequeña y verificable antes de delegar trabajo sensible.

El tiempo de configuración varía según la velocidad de descarga, la autorización del proveedor, las actualizaciones del motor y las integraciones opcionales. Toma cualquier promesa de un tiempo de configuración fijo como algo orientativo, no como una garantía.

Cómo montar por tu cuenta una configuración con contenedores

Este es un esquema genérico:

Host or Docker Desktop VM
├── agent container
├── optional browser container
├── narrow workspace mount
└── local message or control service
        |
        └── configured model and tool providers

Antes de ponerla en marcha, decide:

• Qué directorios del host se montan y si son de solo lectura
• Si algún contenedor recibe el socket de Docker o dispositivos del host
• A qué destinos salientes y servicios locales se puede llegar
• Cómo se acotan y se rotan los secretos
• Qué límites de CPU, memoria, procesos, tiempo, almacenamiento y gasto se aplican
• Cómo se registran los comandos y las llamadas a herramientas
• Cómo se gestionan las actualizaciones y las dependencias vulnerables

La contenerización solo ayuda cuando la configuración se ajusta al modelo de amenazas.

Modelos locales y funcionamiento sin conexión

Un servidor de modelos local compatible puede mantener la inferencia del modelo en tu hardware. Comprueba:

• Si el runtime del agente admite la API del servidor
• Si el modelo sabe seguir esquemas de herramientas de forma fiable
• Los requisitos de contexto y de memoria
• La aceleración por hardware y la memoria necesaria
• Las condiciones de licencia y de redistribución
• Qué otras integraciones siguen usando la red

Un «modelo local» no hace que todo el flujo de trabajo funcione sin conexión si el navegador, Telegram, la búsqueda, las actualizaciones o las herramientas de datos siguen activos.

Coste y rendimiento

No existe una cifra mensual universal que sea honesta. Calcula:

• El coste del producto o del framework
• La suscripción o el uso de API a las tarifas oficiales actuales
• El cómputo y el almacenamiento, locales o en la nube
• Las herramientas de pago y los datos externos
• El tiempo que dedican las personas a configurar, revisar y corregir
• Los intentos fallidos y el trabajo desatendido en segundo plano

El rendimiento también depende del proveedor, de la red, del tamaño del contexto, de la carga de trabajo local del navegador y de las herramientas, y de la máquina. Mide tareas representativas en el ordenador de destino en lugar de suponer que la orquestación local añade una latencia despreciable.

En El coste real de ejecutar agentes de IA tienes una hoja de trabajo para medirlo.

Plataformas de agentes locales frente a alojadas

Ninguna de las dos columnas es de por sí más barata, más segura o más fácil. Compara los productos concretos y tus requisitos de operación.

Puntos clave

• La orquestación local puede mantener el estado y los archivos de trabajo en tu máquina aunque siga usando modelos y herramientas externos
• noHuman Team es una aplicación nativa para macOS y Windows, no un sandbox de Docker
• El aislamiento de Docker depende de los montajes, del acceso al socket, de los privilegios, de las redes, de los secretos y de los límites configurados
• La compatibilidad con proveedores y modelos puede cambiar según el acceso de la cuenta y las versiones del motor instaladas
• Mide el coste, el rendimiento y el flujo de datos con tu trabajo real

Preguntas frecuentes

¿Necesito Docker para ejecutar agentes de IA en local?

Depende del producto. noHuman Team no requiere Docker. Muchos frameworks autoalojados usan contenedores para empaquetar y aislar. Lee los requisitos actuales del runtime que elijas.

¿Necesito una clave de API?

No siempre. noHuman Team admite ciertos motores que funcionan con suscripción, además de proveedores con clave de API. Un framework que montes por tu cuenta puede requerir una clave de API o un endpoint de modelo local compatible.

¿Necesito una GPU?

No, si la inferencia del modelo se hace en un proveedor alojado. La inferencia de modelos locales puede beneficiarse de una aceleración y una memoria adecuadas, o requerirlas. La automatización del navegador y las herramientas de desarrollo siguen consumiendo CPU y RAM locales.

¿Cuánto cuesta ejecutar agentes de IA en local?

Depende del software, del acceso al modelo, del uso, de las herramientas, de la infraestructura y del tiempo de revisión. Usa los precios oficiales vigentes de los proveedores y el uso medido en tareas representativas en lugar de un rango mensual genérico.

¿Es seguro dejar que un agente local ejecute código?

La seguridad depende de los permisos y del aislamiento. Un agente nativo puede tener el mismo acceso al sistema de archivos que el usuario. Un contenedor puede acotar el acceso, pero su configuración puede exponer rutas del host o privilegios altos. Da solo los privilegios imprescindibles para la tarea y exige revisión en las acciones de alto impacto.

¿Local significa que mis datos nunca salen del ordenador?

No. Los prompts pueden ir a un proveedor de modelos, las tareas de navegador se conectan a sitios web y las integraciones opcionales, a sus servicios. Identifica y aprueba esos flujos antes de usar datos sensibles.

¿Quieres un equipo local nativo? Consigue noHuman Team para macOS o Windows, conecta una suscripción compatible o un proveedor con clave de API y empieza con una carpeta de trabajo y una tarea que puedas verificar.