Agente de programación con IA autoalojado — Guía completa

Un agente de programación con IA se vuelve verdaderamente autoalojado solo cuando en su hardware se ejecuta algo más que su interfaz de escritorio. Para que el código permanezca dentro de su entorno, la aplicación, la inferencia del modelo, los embeddings, los registros, las herramientas y el repositorio deben mantenerse dentro de su perímetro. Una implementación segura empieza con un repositorio de prueba aislado, un sandbox sin privilegios de administrador, salida de red restringida, un modelo local de tamaño adecuado y aprobación humana para cada escritura relevante.

Cuatro estados de implementación que la gente llama “autoalojados”

1. Aplicación local con un modelo alojado

La interfaz y las herramientas del agente se ejecutan en su ordenador, pero parte del código y de los prompts se envían a un proveedor de API. Es ejecución local, no inferencia completamente local.

2. Aplicación autoalojada con un endpoint privado

Su equipo opera la aplicación y la conecta a un endpoint de modelo en una VPC, nube privada o gateway local. La ruta de datos puede controlarse estrechamente, pero aún depende del diseño de alojamiento y registro del endpoint.

3. Inferencia completamente local

La aplicación, los pesos del modelo, los embeddings, los registros y las herramientas permanecen en hardware propio. Solo este estado justifica afirmar que «el código no sale del entorno», y únicamente después de comprobar la telemetría, los informes de fallos, los gestores de paquetes, los conectores y los servicios de actualización.

4. Implementación aislada de la red

No existe ninguna ruta de red. Las imágenes, los paquetes, los modelos, los datos de vulnerabilidades y las actualizaciones entran mediante un proceso offline aprobado. Un modelo local con una conexión de red activa no está aislado de la red.

Arquitectura de referencia

Desarrollador
   ↓
Arnés Eigent / de agente de programación
   ↓
Puerta de políticas y aprobación
   ↓
Herramientas de repositorio aisladas ── Git, pruebas, linters, escáneres
   ↓
Endpoint de modelo privado ── registros locales y almacén de evaluación

El repositorio de la aplicación de Eigent tiene licencia Apache-2.0. Su inicio rápido de código fuente puede conectarse a Eigent cloud, mientras que el repositorio dirige a los usuarios independientes a una ruta de implementación local separada (repositorio de Eigent). Utilice y verifique la ruta independiente cuando el objetivo sea el aislamiento de datos.

Otros arneses pueden ajustarse a flujos de trabajo distintos. OpenHands ofrece un núcleo con licencia MIT y backends Docker, VM, locales y en la nube (repositorio de OpenHands). Cline proporciona un agente IDE/CLI Apache-2.0 con aprobaciones (repositorio de Cline). Aider ofrece un bucle de terminal nativo de Git con licencia Apache-2.0 (repositorio de Aider).

La comparación de agentes de programación con IA de código abierto separa estos arneses por interfaz, estado de mantenimiento, modelo de implementación y diseño de aprobaciones.

Elija un arnés de agente de programación con IA

No elija solo por la interfaz. Valide cómo la herramienta limita los archivos, ejecuta comandos, almacena prompts, envía telemetría, gestiona secretos y registra llamadas a herramientas.

Dimensione el hardware según la carga de trabajo, no con un mínimo ficticio

No existe una regla universal honesta de «8 GB son suficientes». El hardware depende del artefacto del modelo, la cuantización, la longitud de contexto, los agentes concurrentes, el índice del repositorio y la latencia requerida.

Ollama admite GPU NVIDIA, Apple Metal y una ruta Vulkan experimental. Su planificador comprueba la VRAM disponible y su vista de procesos muestra si un modelo está en GPU, CPU o dividido entre ambas (documentación de GPU de Ollama, preguntas frecuentes de Ollama). Para servir a equipos, vLLM es una opción orientada a producción, pero la compatibilidad de aceleradores e imágenes cambia; use la documentación de instalación de vLLM actual.

Los pesos abiertos no garantizan una implementación en portátil. La tarjeta oficial del modelo Kimi K2 enumera un billón de parámetros totales, lo que ilustra que un modelo descargable todavía puede requerir una infraestructura considerable (tarjeta de modelo de Kimi K2).

Un procedimiento de implementación que prioriza el sandbox

1. Modele las amenazas antes de instalar

Clasifique el código fuente, los secretos, los datos de clientes, los artefactos de compilación y los registros. Enumere quién puede iniciar una tarea, qué acciones puede realizar el agente y qué fallos serían inaceptables.

NIST SP 800-218A amplía las directrices de desarrollo seguro de software para la IA generativa y está dirigido a productores y adquirentes de sistemas de IA (NIST). Úselo como referencia de gobernanza, no como prueba de que una herramienta o implementación «cumple con NIST».

2. Cree un entorno de ejecución aislado

Ejecute el agente con una identidad dedicada sin privilegios de administrador en un contenedor o VM. Deniegue acceso al directorio de inicio, claves SSH, credenciales de nube, perfiles de navegador, gestores de contraseñas y montajes de producción.

OpenHands advierte explícitamente que un agente local sin sandbox tiene acceso completo al sistema de archivos (repositorio de OpenHands). Ese riesgo se aplica conceptualmente a cualquier agente de programación con autoridad de shell.

3. Clone un repositorio de prueba sintético

Use código sin datos de clientes ni secretos. Monte solo ese directorio. Añada archivos canario fuera del montaje y verifique que el agente no puede leerlos.

4. Implemente la ruta de aplicación independiente

Siga la documentación actual de implementación local de Eigent referenciada por su repositorio oficial, no un inicio rápido conectado a la nube (repositorio de Eigent). Registre el commit exacto, las imágenes, las dependencias y la configuración utilizados.

5. Conecte un modelo local

Elija un modelo que se ajuste al hardware y la tarea medidos. Confirme la ubicación del proceso, la latencia, el manejo del contexto y la calidad de salida. Trate un endpoint alojado como una línea base de calidad no local, claramente etiquetada.

6. Restrinja la salida de red

Bloquee el tráfico saliente y luego observe qué falla. Inspeccione DNS, comprobaciones de actualización, telemetría, informes de fallos, gestores de paquetes, herramientas de navegador, servidores MCP y descargas de modelos. Documente cada excepción.

7. Cree herramientas con alcance limitado

Comience con acceso de lectura/escritura al repositorio y una lista de permitidos de comandos de compilación, prueba, lint y formato. Deniegue implementaciones, cambios de identidad, administración de nube, instalación arbitraria de paquetes y mensajería externa.

8. Añada puertas de aprobación

Exija aprobación para escrituras de archivos, ejecución de comandos, dependencias, uso de red y cualquier acción fuera del repositorio. La política determinista debe bloquear operaciones prohibidas aunque el modelo las solicite de forma persuasiva.

9. Ejecute un conjunto de evaluación

Use las mismas tareas para cada modelo y arnés: corrección de errores, refactorización de varios archivos, creación de pruebas, actualización de dependencias, explicación de código y negativa a modificar archivos fuera del alcance. Puntúe la corrección, la tasa de éxito de pruebas, el tiempo de revisión, los intentos de violación de límites, la latencia y el coste.

10. Introduzca secretos mediante un intermediario

Solo después de que la evaluación sintética sea satisfactoria debe el agente recibir credenciales de alcance reducido y corta duración. Mantenga los secretos fuera de los prompts y registros. Prefiera un intermediario que conceda una acción en lugar de un token de administrador reutilizable.

Riesgos de seguridad exclusivos de la programación agéntica

Un análisis de seguridad de 2026 destaca la inyección indirecta de prompts, el comportamiento de delegado confundido y los fallos en cascada en sistemas de agentes de larga duración, y recomienda sandboxing y controles deterministas para acciones de alta consecuencia (artículo de investigación). Los agentes de programación se exponen a estos riesgos a través de incidencias, archivos README, comentarios, metadatos de dependencias, páginas web y salida de herramientas.

Los controles deben incluir:

• etiquetas de contenido no fiable para texto de repositorio y web;
• separación estricta entre leer instrucciones y conceder permisos;
• límites de consultas, filas, tiempo y salida;
• registros de paquetes permitidos y revisión de dependencias;
• registros inmutables de prompts, llamadas a herramientas, diffs y aprobaciones;
• revisión humana antes de fusionar, publicar o implementar;
• reversión mediante Git y entornos reproducibles.

El autoalojamiento reduce un límite externo de datos. Hace que su equipo sea responsable del parcheo, la seguridad del entorno de ejecución, la gestión de claves, la supervisión y la respuesta a incidentes.

Extienda la implementación a un entorno aislado de la red

Un agente aislado de la red necesita más que una casilla de inferencia local.

1. Refleje imágenes de contenedor, paquetes, artefactos de modelo y datos de vulnerabilidades aprobados.
2. Verifique hashes y firmas antes de la importación offline.
3. Mantenga un inventario y una lista de materiales de software.
4. Desactive actualizaciones automáticas, telemetría y conectores que supongan acceso a internet.
5. Proporcione registros offline de paquetes y modelos.
6. Defina una ruta de exportación firmada para parches e informes.
7. Programe actualizaciones de seguridad offline y procedimientos de revocación de emergencia.
8. Pruebe que el entorno no tiene ruta mediante DNS, proxies, interfaces de gestión ni herramientas de modelos.

Los entornos aislados de la red aumentan la carga de actualización y operaciones. No eliminan el riesgo interno, las dependencias maliciosas, los documentos importados inseguros ni los errores del modelo.

Cumplimiento y evidencia

Ningún agente de programación autoalojado hace que un equipo cumpla automáticamente GDPR, HIPAA, SOC 2, ISO 27001, controles de exportación o confidencialidad contractual. El cumplimiento depende de la implementación, las personas, las políticas, los contratos y la evidencia.

Documente las licencias de modelos y conjuntos de datos, la SBOM, la política de acceso, la matriz de aprobaciones, la retención de registros, las copias de seguridad, la recuperación ante desastres, la respuesta a vulnerabilidades y la reversión. Trate los registros de prompts y herramientas como potencialmente sensibles porque pueden contener fragmentos de código fuente y secretos.

Cuándo es mejor un agente de programación alojado

Use un agente alojado cuando el equipo no pueda operar infraestructura de modelos, necesite un entorno remoto maduro, valore el soporte del proveedor o pueda enviar legalmente el contexto requerido al proveedor. Un servicio alojado bien gobernado puede ser más seguro que una implementación autoalojada descuidada.

Use el autoalojamiento cuando los límites de datos, la inspección del código fuente, la elección del modelo, la operación offline o la política personalizada justifiquen la propiedad de ingeniería y seguridad.

Opere el límite del agente de programación con IA, no solo el modelo

Eigent puede proporcionar la capa de orquestación inspeccionable para un flujo de programación privado, pero el sandbox, el tiempo de ejecución del modelo, los permisos, los registros y el proceso de actualización determinan si está realmente autoalojado. Comience con comprender una base de código grande dentro de un repositorio sintético y amplíe solo después de que los controles se mantengan. Descargue Eigent para iniciar la evaluación aislada.