Dar a un agente de inteligencia artificial acceso a tu ordenador es como dejarle las llaves a alguien muy competente, muy rápido y sin sentido común. Va a hacer cosas útiles a una velocidad asombrosa y, de vez en cuando, va a hacer algo que no puedes deshacer. Esta guía trata de que ese día no te pille sin red.
No es una guía teórica de gobernanza. Son siete medidas concretas, ordenadas de más a menos rentables, que puedes aplicar esta misma tarde y que cubren el 90 % de los incidentes reales. Ninguna requiere herramientas de pago ni conocimientos de seguridad avanzados.
Qué puede salir mal de verdad
Antes de proteger conviene saber de qué. Los incidentes reales con agentes se agrupan en cuatro familias, y ninguna es la de la película de robots rebeldes.
- Acción destructiva por malentendido. Le pides limpiar archivos temporales y su idea de temporal incluye tu carpeta de trabajo. No hay malicia: hay ambigüedad.
- Alcance excesivo. Le das credenciales amplias porque acotarlas costaba tiempo y luego usa un permiso que no necesitaba.
- Instrucciones inyectadas. El agente lee una página, un correo o un documento que contiene órdenes disfrazadas de datos, y las obedece.
- Persistencia olvidada. El agente sigue corriendo meses después de que su tarea dejara de tener sentido, con las credenciales intactas.
Lo esencial en 30 segundos
Trabaja siempre sobre algo reversible, dale el mínimo permiso posible, pon caducidad a todo, exige confirmación en lo irreversible y guarda registros donde el agente no pueda escribir. Con eso cubres casi todo.
Paso 1: que todo lo que toque sea reversible
Es la medida con mejor relación entre esfuerzo y protección, y la que más gente se salta.
Si el agente trabaja sobre archivos, que estén bajo control de versiones. No hace falta ser programador: un repositorio local con un commit antes de cada sesión convierte cualquier desastre en un comando de deshacer. Si trabaja sobre una base de datos, que sea una copia, o que tengas una copia de seguridad de menos de una hora.
La pregunta que hay que poder responder antes de darle acceso a cualquier cosa es sencilla: si borra todo esto, ¿cuánto tardo en recuperarlo? Si la respuesta pasa de una hora, no le des acceso todavía.
Este principio es también el que permite trabajar rápido después. Un agente con red de seguridad puede operar con menos supervisión, porque el coste del error baja. Paradójicamente, cuanto mejor sea tu capacidad de deshacer, más autonomía te puedes permitir darle.
Paso 2: el mínimo permiso, y de verdad
«Mínimo privilegio» es un principio antiguo que todo el mundo cita y casi nadie aplica, porque acotar permisos es tedioso y darlos todos funciona a la primera.
La versión práctica para agentes consiste en preguntarse, por cada acceso: ¿qué es lo peor que puede pasar con este permiso? No lo más probable, lo peor. Un agente que solo necesita leer no debe poder escribir. Uno que necesita escribir en una carpeta no debe poder escribir en el sistema. Uno que consulta una base de datos no necesita permiso de borrado.
Hay un caso que merece mención aparte: el correo electrónico. Dar a un agente acceso de envío es de las cosas más arriesgadas que se pueden hacer, porque un error no se deshace: el mensaje ya está en el buzón de otra persona. Si lo necesitas, que escriba borradores y que los envíe un humano.
Paso 3: aislar el entorno
Aquí hay tres niveles según cuánto te la juegues, de menos a más aislamiento.
Nivel básico: un usuario aparte. Crear una cuenta de sistema distinta para el agente, con acceso solo a un directorio concreto, cuesta cinco minutos y evita que un comando desafortunado alcance tus documentos personales.
Nivel medio: un contenedor. Ejecutar el agente dentro de un contenedor le da un sistema de archivos propio y aislado. Lo que rompa dentro se arregla borrando el contenedor y creando otro. Es el punto dulce para la mayoría de usos.
Nivel alto: una máquina distinta. Si el agente maneja datos sensibles o tiene mucha autonomía, un equipo separado es la contención más simple de razonar: lo que pase ahí, se queda ahí. Un mini PC dedicado cumple de sobra y consume poco, y en nuestro caso es exactamente la solución que usamos para separar los procesos automáticos del equipo de trabajo.
Un aviso sobre la red, que se pasa por alto constantemente: el aislamiento de disco no es aislamiento de red. Un agente en un contenedor sin acceso a tus archivos puede seguir llegando a cualquier servicio de tu red local. Si eso importa, hay que limitarlo explícitamente.
Paso 4: credenciales con fecha de caducidad
Ya lo mencionamos al analizar la propuesta legislativa sobre agentes descontrolados, y lo repetimos porque es la medida que resuelve una categoría entera de problemas mientras duermes.
Un agente con un token permanente es un agente que seguirá funcionando cuando ya nadie recuerde por qué existe. Con rotación cada treinta o noventa días, el agente olvidado se apaga solo y su credencial deja de servir.
La objeción habitual es que rotar da trabajo. Y es cierto la primera vez; después es automático. Comparado con investigar por qué un proceso que nadie mantiene lleva meses accediendo a un sistema, el trabajo es ridículo.
Regla complementaria: una credencial por agente. Compartir la misma clave entre varios hace imposible saber cuál hizo qué, y revocarla los tumba a todos.
Paso 5: confirmación humana en lo irreversible
No todas las acciones son iguales. Leer un archivo es reversible; borrar una tabla no. Escribir un borrador es reversible; enviar un correo o hacer un pago no.
La medida consiste en clasificar las acciones en dos cajas y exigir aprobación explícita para las de la segunda. Los marcos modernos de agentes lo soportan de serie: el flujo se detiene, te pregunta y continúa cuando confirmas.
El error frecuente es poner confirmación en todo, porque entonces la gente empieza a aprobar sin leer y la protección desaparece. Una confirmación que se acepta automáticamente no es una protección, es un ritual. Pocas, bien elegidas y con la información necesaria para decidir.
Si construyes tus agentes con las herramientas que cubrimos en el tutorial de agentes con MCP o con el SDK de agentes, este control está disponible por configuración y no hay que programarlo.
Paso 6: registros que el agente no pueda tocar
El día que algo salga mal, la única pregunta que importa es qué hizo exactamente y en qué orden. Si esa información no existe o el propio agente pudo alterarla, el incidente se queda sin explicación y se repetirá.
La implementación no tiene por qué ser sofisticada. Basta con que el agente escriba su actividad en un destino donde tenga permiso de escritura pero no de borrado ni modificación. Un almacenamiento configurado así, un canal de mensajería dedicado o incluso un archivo en una máquina distinta cumplen el propósito.
Qué registrar, como mínimo: qué acción intentó, con qué parámetros, qué devolvió y de dónde salió la instrucción que la motivó. Ese último campo es el que casi nadie guarda y el único que permite detectar una instrucción inyectada.
Paso 7: la defensa contra instrucciones inyectadas
Dejamos para el final el problema más difícil y el que menos solución limpia tiene.
Un agente que procesa texto de fuera —correos, páginas, documentos, comentarios— está leyendo contenido escrito por desconocidos. Si no distingue entre «esto son datos que debo analizar» y «esto son instrucciones que debo cumplir», cualquiera que consiga poner texto en su camino puede darle órdenes.
No hay una solución completa hoy. Lo que sí hay son mitigaciones que reducen mucho el riesgo:
- Separa los canales. Las instrucciones del sistema y el contenido a procesar deben ir por vías distintas y estar claramente marcadas, no concatenados en el mismo bloque de texto.
- Desconfía del contenido externo por defecto. Trátalo como entrada hostil, igual que harías con lo que escribe un usuario en un formulario.
- Limita lo que puede hacer tras leer. Un agente que acaba de procesar contenido externo no debería poder ejecutar acciones irreversibles sin pasar por confirmación.
- Registra la procedencia. Saber qué leyó justo antes de hacer algo raro es lo único que permite reconstruir el ataque.
Y una nota de humildad: los ensayos en los que modelos frontera consiguieron salirse de su entorno de pruebas demuestran que estas contenciones no son perfectas. Son capas que reducen probabilidad y limitan daño, no garantías.
La lista de comprobación
Resumido en algo que puedes pegar donde lo veas antes de dar acceso a un agente nuevo:
| Comprobación | Si la respuesta es «no» |
|---|---|
| ¿Puedo deshacer lo que toque? | Ponlo bajo control de versiones o copia antes |
| ¿Tiene el mínimo permiso posible? | Quita accesos hasta que algo falle |
| ¿Está aislado del resto? | Usuario aparte, contenedor o máquina separada |
| ¿Su credencial caduca? | Ponle caducidad, hoy |
| ¿Pide confirmación en lo irreversible? | Clasifica acciones y añade el control |
| ¿Deja registro que no pueda borrar? | Redirige los registros fuera de su alcance |
| ¿Sé cómo apagarlo ahora mismo? | Escríbelo antes de arrancarlo |
Un caso práctico: el agente que publica
Bajemos a un ejemplo real. Supongamos un agente que redacta contenido y lo publica en una web.
La versión insegura es evidente y la hemos visto muchas veces: credenciales de administrador de la base de datos, permiso de escritura y borrado, ejecución sin supervisión y sin registro. Funciona perfectamente hasta el día en que una instrucción ambigua le hace sobrescribir contenido existente.
La versión sensata cambia cuatro cosas. El agente escribe en un directorio local, no en la base de datos. Un proceso distinto, con sus propias credenciales acotadas, es el que publica. La publicación exige confirmación humana. Y antes de cualquier operación masiva se hace copia de seguridad.
Es más trabajo montarlo, sí. Pero la diferencia entre las dos versiones es que en la segunda el peor caso es «hay que revisar unos archivos» y en la primera es «hay que restaurar la web». Nosotros aprendimos esto por el camino difícil y ahora hacemos copia antes de cualquier cambio que afecte a más de un puñado de registros.
Qué necesitas para montarlo
Nada de esto exige equipamiento especial, pero hay tres piezas que lo hacen mucho más llevadero:
- Una máquina separada para los agentes, que es la contención más simple de razonar. Un mini PC sobra, o un equipo compacto silencioso si además vas a ejecutar modelos en local.
- Memoria de sobra, porque cada contenedor aislado tiene su coste. Ver precio actual en Amazon
- Almacenamiento rápido para copias de seguridad frecuentes, que es lo que hace viable el paso 1. Ver precio actual en Amazon
- Pantalla con superficie para vigilar registros y trabajo a la vez. Ver precio actual en Amazon
- Ratón ergonómico para las revisiones largas. Ver precio actual en Amazon
- Silla decente, que auditar es aburrido y se hace sentado. Ver precio actual en Amazon
Si además quieres ejecutar los modelos en local para que ni las instrucciones salgan de tu red, el punto de partida está en la guía para montar tu IA en casa.
Cuánta autonomía darle: los cuatro escalones
Hay una decisión previa a todas las medidas técnicas y que casi nadie toma conscientemente: cuánta correa le das. Conviene pensarlo en escalones, porque se puede subir uno a uno según vaya generando confianza.
Escalón 1: solo lectura y propuesta. El agente analiza y te dice lo que haría, pero no toca nada. Es el modo con el que hay que empezar siempre con una tarea nueva. Aburrido y revelador: en las primeras sesiones descubres malentendidos que habrían causado destrozos.
Escalón 2: escritura en un espacio propio. Puede crear y modificar dentro de un directorio suyo. Nada de lo que haga afecta a lo demás hasta que tú lo muevas. Es el punto dulce para la mayoría de trabajos creativos y de análisis.
Escalón 3: escritura supervisada en el espacio real. Toca lo de verdad, pero las acciones irreversibles pasan por confirmación. Aquí ya hace falta tener resueltos los pasos 1, 4 y 6.
Escalón 4: autonomía completa. Actúa sin supervisión. Solo tiene sentido para tareas muy acotadas, repetidas cientos de veces y cuyo peor caso conoces con exactitud. Es mucho menos frecuente de lo que la publicidad sugiere.
El error más habitual es empezar por el escalón 3 porque el 1 parece una pérdida de tiempo. Nuestra experiencia es la contraria: una tarde en el escalón 1 ahorra una semana de arreglos, y la información que sacas de ver qué habría hecho es exactamente la que necesitas para acotar sus permisos.
El coste de equivocarse en cada dirección
Toda medida de seguridad tiene un coste, y fingir lo contrario lleva a que la gente se las salte. Merece la pena poner los dos errores sobre la mesa.
Pasarse de restrictivo tiene un coste real: el agente pregunta constantemente, hay que aprobar cada paso y al final resulta más lento que hacerlo a mano. Cuando eso pasa, la gente desactiva los controles de golpe en lugar de ajustarlos, y se queda peor que al principio.
Quedarse corto tiene un coste distinto: casi siempre cero, hasta el día que no lo es. Y ese día el coste no se reparte, llega entero.
La forma de navegar entre los dos es empezar restrictivo y relajar donde duela, nunca al revés. Si cada día apruebas la misma acción rutinaria diez veces, esa acción merece pasar a la lista de reversibles. Si una confirmación te ha salvado alguna vez, se queda.
Y una observación sobre la naturaleza humana que vale más que cualquier configuración: las protecciones que molestan mucho acaban desactivadas. Un sistema imperfecto que la gente usa protege más que uno perfecto que todos se saltan. Diseña para lo segundo y tendrás lo primero.
Qué no cubre esta guía
Por honestidad, tres cosas que quedan fuera y que conviene saber.
No cubre el cumplimiento normativo. Si tratas datos personales, hay obligaciones legales que van más allá de la higiene técnica y que dependen de tu caso concreto. El punto de partida está en la guía del reglamento europeo, pero para un caso real hace falta asesoramiento.
No cubre la seguridad del modelo en sí: si el proveedor tiene una brecha, ninguna de estas medidas te protege. Eso se gestiona eligiendo proveedor y, cuando importa mucho, ejecutando en local.
Y no cubre los entornos con muchos usuarios. Todo lo anterior asume que tú controlas el agente. Cuando varias personas despliegan agentes en la misma red, hace falta además gobernanza: inventario central, propietario asignado y revisión periódica. Ahí es donde entra lo que cuenta la propuesta legislativa que analizamos aparte.
Preguntas frecuentes
¿Es peligroso dar acceso a mi ordenador a un agente de IA?
Tiene riesgos reales, aunque casi nunca son los que se imaginan. Los incidentes habituales son acciones destructivas por malentendido, permisos excesivos, instrucciones inyectadas en contenido externo y agentes olvidados que siguen activos. Todos se mitigan mucho con medidas sencillas.
¿Qué es la inyección de instrucciones?
Un ataque en el que alguien escribe órdenes dentro de un contenido que el agente va a leer, como una página web o un correo. Si el agente no distingue entre datos e instrucciones, las obedece. No requiere vulnerar nada.
¿Basta con un contenedor para estar seguro?
Ayuda mucho pero no basta. Un contenedor aísla el sistema de archivos, no la red: el agente puede seguir alcanzando servicios de tu red local. Si eso importa, hay que limitar también su acceso de red.
¿Cuál es la medida más rentable si solo puedo hacer una?
Que todo lo que toque sea reversible: control de versiones o copia de seguridad reciente. Convierte cualquier desastre en un contratiempo y permite darle más autonomía con menos miedo.
¿Debo pedir confirmación en todas las acciones?
No. Si pides confirmación en todo, se aprueba sin leer y la protección desaparece. Clasifica las acciones en reversibles e irreversibles y exige aprobación solo en las segundas.
¿Por qué los registros no deben poder alterarse?
Porque el día que algo salga mal, reconstruir qué hizo el agente y qué leyó justo antes es la única forma de entender el incidente. Si el propio agente pudo borrar o modificar el registro, no sirve como prueba.
¿Esto lo exige alguna ley?
Todavía no de forma general. Hay una propuesta en Estados Unidos que obligaría a inventariar agentes y mantener registros inalterables, voluntaria salvo para contratistas federales. En Europa, el reglamento de inteligencia artificial aborda el problema desde el riesgo del caso de uso.
Veredicto Arkaia
Los agentes son la herramienta más útil que ha dado esta generación de modelos y también la que más daño puede hacer sin querer. La buena noticia es que las medidas que los hacen seguros son antiguas y conocidas: reversibilidad, mínimo privilegio, aislamiento, caducidad y auditoría. No hay que inventar nada.
Nuestro consejo Arkaia
Empieza por el paso 1 y no pases de ahí hasta tenerlo. Un agente que trabaja sobre algo que puedes deshacer en un minuto se puede dejar suelto con relativa tranquilidad; uno que toca cosas irrecuperables no debería tener autonomía por muchas otras capas que le pongas. Y si solo vas a hacer dos cosas, que la segunda sea poner caducidad a las credenciales: se hace en una tarde y elimina la categoría de incidente más común.
Lecturas relacionadas
- Stop Rogue AI Act: inventariar los agentes que tienes sueltos
- Modelos frontera que se salen del entorno de pruebas
- Crear un agente con la API de Claude y MCP
- Tutorial del SDK de agentes en Python
- Crear un servidor MCP en TypeScript
- Programar desde la terminal con IA
- Guía del reglamento europeo de inteligencia artificial
Este artículo contiene enlaces afiliados a Amazon con el tag arkaiacorp-21. Si compras a través de estos enlaces, Arkaia puede recibir una comisión sin coste adicional para ti. Nuestra valoración editorial es independiente y no varía según los ingresos por afiliación.
Comentarios
Inicia sesion para dejar un comentario
Acceder
