Agentes personales autoalojados y sus riesgos

¿Por qué se convirtió esto en una categoría aparte en 2026?

Si todavía no queda claro qué convierte un programa en agent y no en una ventana de chat, lo resume el post qué hace un agent , paso a paso. Hace dos años « IAlocal» significaba charlar con un modelo pequeño en tu propio equipo. En 2026 apareció en el catálogo de modelos una formulación nueva: modelos construidos «para agents locales siempre activos», afinados expresamente para el uso de herramientas, las tareas largas y la recuperación tras un error, sobre hardware de consumo.

Los órdenes de magnitud con los que hay que contar:

El tamaño de descarga no es lo mismo que la memoria necesaria. En uno de los modelos pensados para agents el fabricante lo escribe aparte: hacen falta al menos 36 GB de memoria en un equipo de escritorio normal, aunque su descarga sea de 20 GB (la fila de 36–67 GB de la tabla anterior, en cambio, es el tamaño de descarga de las variantes con más precisión). Esta es la fuente de decepción más frecuente.

La trampa en la que cae casi todo el mundo

Este es el dato más práctico del artículo, y solo por él ya merece la pena leerlo.

La ventana de contexto por defecto de los ejecutores locales de modelos más extendidos es de 4.096 tokens.

Te descargas el modelo cuya descripción habla de un contexto de 256.000 tokens — y corre con cuatro mil noventa y seis, salvo que lo cambies a mano con una variable de entorno.

Para charlar es imperceptible. Para una tarea de agent es mortal: un solo fichero algo largo o unas pocas llamadas a herramientas se lo comen, y a partir de ahí el agent olvida qué hizo tres pasos antes. El síntoma no es un mensaje de error, sino torpeza — y la gente culpa al modelo, no al ajuste. Qué significa exactamente la ventana de contexto lo cuenta el post el token y el context window , con ejemplos.

¿Cuánto más flojo es el modelo local? — medido

Aquí hay que ser honesto, porque la diferencia no es pequeña.

De una medición universitaria independiente sobre llamada a funciones (estado de abril de 2026):

Y el detalle más importante: en los modelos pequeños la tarea de varios turnos sencillamente se desploma.

Esta es la medición más importante del artículo. El uso de herramientas de una sola llamada — «mira qué tiempo hace» — los modelos pequeños lo saben hasta cierto punto. La tarea de agent con varios turnos, que arrastra estado, es donde el modelo local toca fondo. Y no es una diferencia del diez o el veinte por ciento, es un orden de magnitud.

Aquí hace falta, eso sí, un contrapunto importante. En la misma medición, un modelo de pesos abiertos y licencia permisiva alcanzó prácticamente al modelo cerrado puntero en la categoría de varios turnos (68,0 % frente a 68,4 %), a una fracción del coste.

Pero: peso abierto no equivale a ejecutable en un portátil. Ese modelo es bastante mayor de lo que aguanta un ordenador portátil. Para qué sirven los pesos abiertos lo trata el post los pesos abiertos , aunque esa es otra cuestión distinta de si te cabe en el equipo.

(La medición citada se actualizó por última vez en abril de 2026, así que no incluye los modelos más recientes. El sentido de la brecha es probablemente duradero; su valor exacto, no.)

Lo que alcanza por defecto — y ahí está la cosa

La documentación del agent personal abierto y de ejecución local más extendido es inusualmente directa. Tres frases suyas, que conviene leer al pie de la letra:

• «El sandbox está desactivado por defecto.»
• «Las herramientas se ejecutan en la máquina anfitriona en la sesión principal, salvo que configures el sandbox.»
• Y activado tampoco es perfecto: «no es un límite de seguridad perfecto, pero restringe de forma apreciable el acceso al sistema de ficheros y a los procesos.»

¿Qué significa esto en concreto? La lista de capacidades, de la propia descripción del fabricante: correo, calendario, navegación web, operaciones con ficheros, ejecución de comandos de shell y memoria persistente entre conversaciones.

O sea, con los ajustes por defecto, un programa que ejecuta comandos en tu equipo, lee tu correo y se acuerda. Por separado son capacidades útiles. Juntas, sin sandboxy leyendo texto que llega de internet, es el montaje más arriesgado que se puede poner en marcha en casa.

La frase que todo el mundo debería leer

La política de seguridad enumera qué no cuenta como vulnerabilidad reportable. Esa parte es más honesta que cualquier material de marketing:

NO CUENTA COMO FALLO DE SEGURIDAD

- prompt injection, si no salta una política, la
  autenticación, una aprobación, el sandbox o un
  límite de herramienta;

- que un operador de confianza use una función
  local deliberada - por ejemplo acceso al shell
  local o ejecución de scripts;

- una extensión maliciosa, después de que un
  operador de confianza la instale o la habilite.

Y la frase que lo enmarca:
"Quien pueda operar un agent puede hacerle hacer
 cualquier cosa que ese agent sepa hacer."

Traducido: si tu agent personal tiene acceso al shell, entonces el prompt injection no es una vulnerabilidad, es el funcionamiento del sistema. No habrá arreglo, porque no hay nada que arreglar: la capacidad se la diste tú.

Esto no es un reproche a los desarrolladores; al contrario, es el encuadre correcto y honesto. Pero significa que la seguridad la tienes que construir tú, no esperarla del software. La mecánica del ataque la explica la introducción a los fundamentos del prompt injection , y el estrechamiento de permisos lo trata el post el agent con los permisos mínimos , punto por punto.

Los riesgos documentados

La lista de riesgos del propio fabricante, porque está más detallada que lo que se podría reunir desde fuera:

Lo que sí está bien puesto por defecto: el proceso principal solo escucha en la dirección de red propia del equipo (o sea, no se llega desde fuera), y la mayoría de los canales de mensajería pide un código de emparejamiento a un remitente desconocido. Pero la instalación en contenedor abre hacia fuera por defecto — y ese es justo el paso que da todo el mundo en un fin de semana de «me monto mi propio agent», para llegar desde el otro equipo.

Que esto no es teórico: una vulnerabilidad de 2024 en uno de los ejecutores locales de modelos más extendidos permitía ejecución remota de código, y en el momento del aviso había más de mil instancias expuestas accesibles en internet. Como circunstancia agravante, los investigadores destacaron aparte que la instalación en contenedor corre con permisos de administrador y escucha en todas las interfaces de red. Los desarrolladores lo arreglaron en cuatro horas; las instancias expuestas, en cambio, siguieron ahí durante semanas.

(Es un caso de 2024. De 2025–2026 no he podido confirmar ninguna pérdida de datos documentada públicamente y causada por un agent local, lo que no prueba que no haya ocurrido.)

¿Hay ventaja en privacidad?

Este es el motivo más común por el que alguien se mete en un agent local. La respuesta: sí, pero no donde la mayoría cree.

Donde es cierto de verdad:

• El estado, la memoria y las credenciales se quedan en tu hardware.
• Las buenas soluciones no mandan telemetría por defecto: nada más allá de una comprobación diaria de versión, y esa también se puede desactivar.
• No hay retención de datos del proveedor, porque no hay proveedor.

Hay además un argumento fuerte a favor que rara vez sale: en los servicios de agents gestionados en la nube, el propio proveedor escribe que, por el funcionamiento con estado, ese servicio concreto no sirve para retención de datos cero ni para ciertos acuerdos de privacidad sanitaria. Quien se va a lo local por privacidad tiene aquí su mejor argumento.

Donde en cambio NO es cierto — y hay que decirlo:

1. La captura de pantalla sale del equipo. Una constatación judicial recogió literalmente, sobre un browser agent, que el programa hace capturas del navegador, las envía desde el equipo del usuario a los servidores del proveedor y de ahí recibe la instrucción de cómo seguir navegando. Que «corre en local» no significa que el contenido se quede en local.

2. El armazón local a menudo llama a un modelo en la nube. El entorno de ejecución local y el modelo local son dos cosas distintas. Que el agent corra en tu equipo no impide que el razonamiento se vaya a la nube, y con él los datos.

3. Las extensiones. El mercado de extensiones es un mundo aparte y, como quedó dicho arriba, la extensión maliciosa después de instalada no cuenta como fallo de seguridad. De lo que instales respondes tú.

4. Los registros están en tu equipo, pero están. Si activas el registro detallado, los prompts, las entradas de las herramientas e incluso las peticiones completas acaban en disco. El mismo riesgo, solo que de tu lado, y a menudo sin cifrar. La cuestión de dónde se guardan los datos la desarrolla con más detalle el post el almacenamiento de datos en la UE , con la normativa.

¿Qué configurar antes de arrancarlo?

Diez puntos, todos salidos de documentación primaria o de un incidente documentado, no de una opinión:

1. ACTIVA EL SANDBOX
   Viene desactivado. No es un límite perfecto,
   pero restringe de forma apreciable.

2. CAMBIA LA VENTANA DE CONTEXTO
   El valor por defecto es 4096 tokens. Es poco.

3. NO LO EXPONGAS A LA RED SIN AUTENTICACIÓN
   La instalación en contenedor abre hacia fuera.
   Instancias así expuestas: más de mil.

4. LISTA DE DOMINIOS PERMITIDOS
   Limita adónde puede salir. Es la defensa más
   barata contra la exfiltración.

5. NO LE DES TUS CONTRASEÑAS
   Cuenta aparte, perfil aparte, permisos mínimos.

6. APROBACIÓN HUMANA EN LOS PASOS CON CONSECUENCIAS
   Operación financiera, firma, envío de correo.

7. MÁQUINA VIRTUAL O CONTENEDOR DEDICADO
   No en tu equipo principal, junto a tus ficheros.

8. EL CONTENIDO DE LA PANTALLA NO ES UNA ORDEN
   Lo que el agent lee en una página es dato.
   No puede otorgar permisos.

9. ALLOWLIST DE REMITENTES
   Si se controla por mensaje, solo remitentes
   conocidos. Quien le escriba puede aprobar por ti.

10. MIRA QUÉ ACABA EN EL REGISTRO Y EN EL .ENV
    Permisos de fichero, y nunca guardes las claves
    en el directorio de trabajo.

El séptimo punto es el que más aporta con menos trabajo. Si el agent corre en una máquina virtual aparte y solo ve lo que tú le pones delante, el fallo de los otros nueve puntos también causa un daño limitado.

Malentendidos típicos

• «Corre en local, o sea que es privado.» Las capturas de pantalla, las llamadas a modelos en la nube y las extensiones pueden sacar los datos. La ejecución local hace local el almacenamiento, no necesariamente el procesamiento.
• «Para un agent sencillo basta un modelo pequeño.» Para una sola llamada, sí. Para una tarea de varios turnos que arrastra estado, en la medición, de 12.000 millones de parámetros hacia abajo, el resultado cayó por debajo del 6 %.
• «Me he bajado el modelo de 256.000 tokens, o sea que ese es mi contexto.» El valor por defecto es 4.096 tokens. Hay que cambiarlo a mano.
• «El modelo de pesos abiertos es más barato y casi igual de bueno.» En algunos modelos abiertos es cierto, pero esos no suelen ser de tamaño portátil. El peso abierto y la ejecución local son dos cosas distintas.
• «Si aparece un agujero de seguridad, ya lo arreglarán.» El prompt injection a través del acceso local al shell los desarrolladores expresamente no lo consideran un fallo de seguridad. No hay nada que arreglar ahí.
• «Solo llego yo, está en casa.» Hasta que lo cambias para llegar también desde tu otro equipo. En el incidente documentado ese fue justo el punto de entrada.

Lo que conviene llevarse

El agent que corre en tu propio equipo da libertad de verdad: sin suscripción, sin límites de contenido, con los datos en tu disco. A cambio, el límite de seguridad lo tienes que construir tú, porque el software no promete expresamente hacerlo por ti.

Dos cifras deciden si merece la pena: 27 puntos porcentuales de brecha en las tareas de agent de varios turnos frente a los modelos cerrados punteros, y 4.096 tokens de ventana de contexto por defecto, que nadie te cuenta. Por lo primero, el agent local hoy sirve mejor para tareas bien delimitadas que como asistente general; por lo segundo, mucha gente ni siquiera llega a experimentar eso.

Y si solo vas a configurar una cosa: ponlo en una máquina virtual aparte. Ese único paso limita las consecuencias de la mayoría de los errores, y no exige más que media hora de paciencia. Qué recuerdos duraderos reúne un agent sobre ti por el camino lo cuenta el post la agent memory , con casos. Cómo se ve esa construcción del límite en un sistema propio de verdad lo enseña, decisión a decisión, construir un agent propio, con sus renuncias.