Asistente vs agente: dónde cambia la seguridad de la IA

Los proveedores usan "asistente", "copiloto" y "agente" como matices comerciales de un mismo concepto. En seguridad no son simples matices. Hay una frontera clara, y cruzarla altera lo que puede fallar, quién asume la responsabilidad y qué marco de referencia se debe aplicar.

Esa frontera reside en si el sistema tiene capacidad de actuar, una cuestión bastante más concreta que la autonomía en abstracto.

El problema

Una herramienta de soporte empieza redactando borradores de respuesta. Un operador humano revisa cada uno y lo envía. Tras unos meses de ajuste el sistema mejora, y alguien señala que tener a una persona pulsando "enviar" ante un borrador que ya ni lee es puro teatro. Por tanto, se autoriza a la herramienta a enviar de forma directa ciertos tipos definidos de solicitudes.

Nada en el modelo cambió, y el diagrama de arquitectura apenas varió. El modo de fallo sí lo hizo: antes, el peor escenario era un borrador deficiente detectado a tiempo. Después, es un mensaje enviado a un cliente sin intermediarios.

Más adelante se le añade una herramienta para consultar detalles de cuentas, buscando respuestas más precisas. Ahora, el cuerpo de una solicitud hostil es texto que el modelo procesa mientras retiene una credencial con permisos para consultar registros de clientes. La herramienta cruzó la línea dos veces, y ninguno de esos pasos tuvo una revisión de arquitectura, porque cada uno fue un incremento menor sobre algo ya existente.

Por qué en la IA es diferente

Cinco propiedades diferencian a un agente de un asistente. Suelen incorporarse una a una, motivo por el cual la frontera se cruza a menudo sin que nadie se percate.

En primer lugar, retiene una identidad. El sistema se autentica con un rol o cuenta concreta. Una vez que esto ocurre, todo lo que sabes sobre gestión de privilegios entra en juego, con la salvedad de que la entidad que decide qué hacer con esos permisos es probabilística.

En segundo lugar, puede actuar mediante herramientas que escriben, envían, despliegan o procesan pagos. Lo determinante radica en si los efectos de una herramienta son reversibles y si alguien los inspecciona antes de que se consoliden, más que en la simple existencia de dicha herramienta.

En tercer lugar, conserva estado, lo que implica memoria a través de pasos o sesiones. Esta es la propiedad que más se subestima. Conservar estado significa que la influencia de un atacante puede persistir más allá de la conversación donde se originó, riesgo clasificado por OWASP como Memory and Context Poisoning bajo ASI06 [1].

En cuarto lugar, continúa sin ti, ejecutando planes de varios pasos hasta terminarlos. El radio de impacto de una mala decisión se multiplica y abarca toda la secuencia de acciones posteriores en vez de limitarse a una respuesta equivocada.

En quinto lugar, se coordina con otros elementos, ya sea mediante múltiples agentes o mediante un agente que consume herramientas que a su vez son agentes. Riesgos como Insecure Inter-Agent Communication (ASI07) y Cascading Failures (ASI08) existen precisamente porque el fallo de un componente ahora se propaga [1].

El OWASP Top 10 for LLM Applications 2026 sigue aplicando a todo este conjunto: la inyección de prompts es LLM01 tanto si el sistema actúa como si no, y la exposición de contexto oculto es LLM08 en ambos casos [2]. Sin embargo, ese documento no abarca lo que ocurre después de que el modelo toma una decisión, porque fue redactado para aplicaciones que consultan un modelo y no para sistemas que ejecutan acciones a través de él. La lista para agentes cubre ese vacío, partiendo de Agent Goal Hijack en ASI01 y Tool Misuse en ASI02 [1].

Ambos marcos se complementan. Usar únicamente la lista de LLM en un agente deja sin evaluar los riesgos de identidad, memoria y coordinación. Aplicar únicamente la lista de agentes a un asistente impone una sobrecarga innecesaria para capacidades de las que carece.

Lo que realmente funciona

Define a qué lado de la línea se sitúa cada sistema y documéntalo por escrito. Pasa por alto el lenguaje del proveedor y evalúa las cinco preguntas anteriores. Cualquier respuesta afirmativa implica que es un agente, y un agente exige una auditoría diferente.

Coloca la confirmación allí donde se genera el impacto. Que un humano apruebe un plan general es muy distinto a que apruebe cada paso irreversible. La autorización debe ubicarse en el punto de efecto y solo en aquellas acciones que lo ameriten, ya que una confirmación que salta de continuo termina firmándose a ciegas.

Trata la memoria como una entrada externa y no como simple almacenamiento. Cualquier dato que un agente haya guardado en memoria durante una sesión expuesta a contenido no confiable debe considerarse no confiable en la siguiente lectura. Delimita la memoria por usuario y por tarea, y define caducidades. La memoria compartida y persistente entre diferentes inquilinos es la variante de este diseño que termina en desastre.

Otorga al agente una identidad propia en lugar de usar la cuenta de un empleado o una cuenta de servicio genérica. Este es el cambio fundamental que permite atribuir las acciones de un agente y acotar sus permisos, y corresponde a trabajo de infraestructura más que a retoques del modelo.

Acota el bucle con un límite de pasos, un límite de tiempo y un límite de gasto, aplicados desde fuera del agente. Un agente convencido de estar a punto de terminar seguirá intentándolo, y el mecanismo que lo detenga no puede depender de su propio razonamiento.

Monitoriza las acciones más que los tokens. Registrar prompts y respuestas te indica lo que el modelo dijo. Registrar llamadas a herramientas con sus argumentos y resultados te dice lo que hizo, que es el registro imprescindible ante un incidente. La prueba definitiva: si un agente modificó algo el martes pasado, ¿puedes identificar qué llamada exacta lo hizo, bajo qué identidad y con qué parámetros? Si para reconstruir eso necesitas leer transcripciones de chat, estás registrando en la capa equivocada.

Separa los agentes de lectura de los agentes de escritura. Dividir un único agente de propósito general en uno de consulta y otro de acción estrictamente delimitado resta algo de elegancia, pero crea un límite defensivo real: el componente expuesto a datos no confiables no sostiene credenciales de escritura. Además, facilita responder ante un incidente, porque el componente ejecutor contaba con un catálogo reducido y cuantificable de acciones posibles.

Lo que no funciona

Guiarse por la categoría comercial no funciona porque el término "copiloto" responde al marketing y no a la capacidad técnica. Algunos copilotos solo sugieren; otros envían código a producción y disparan pipelines. El nombre comercial no aclara cuál de los dos tienes delante.

Considerar que la intervención humana es un control efectivo sin verificar si es real tampoco funciona. Si una persona aprueba cuarenta acciones al día, actúa como un sello automático y el control es puramente decorativo. Menos autorizaciones pero mejor enfocadas ofrecen mayor seguridad que una avalancha de alertas.

Asumir que las herramientas de solo lectura hacen seguro a un agente es otro error común. Un agente que únicamente lee, pero que tiene acceso a datos de clientes y salida a la red, constituye una vía de exfiltración. El principio de mínimo privilegio aplica con la misma fuerza a las lecturas.

Proteger únicamente el modelo y desentenderse del resto deja la mayor parte del riesgo intacto. Las barreras de seguridad sobre entradas y salidas actúan sobre una capa, pero no resuelven una credencial con permisos excesivos ni una memoria que arrastre instrucciones inyectadas hasta el día siguiente.

Permitir que la línea se cruce por pequeños incrementos es el problema más habitual. Nadie aprueba formalmente construir un agente autónomo de golpe: se aprueba añadir una herramienta, luego eliminar una confirmación y más tarde añadir memoria. Cada paso es modesto; el resultado es un sistema distinto bajo el mismo nombre, que a menudo sigue figurando en el registro de cambios con la etiqueta que tenía cuando solo redactaba borradores.

Confiar en que las configuraciones predeterminadas de los frameworks son prudentes es la última trampa. Los entornos de desarrollo para agentes están optimizados para lograr prototipos funcionales con rapidez, lo que suele implicar acceso amplio a herramientas, memoria persistente habilitada de fábrica y ausencia de límites de pasos. Son valores razonables para una demostración y pésimos para entornos de producción, y rara vez se corrigen a tiempo porque nada falla mientras están mal configurados.

Por dónde empezar

• Enumera tus sistemas de IA y clasifícalos con las cinco propiedades: identidad, acción, estado, continuidad y coordinación. Aquellos con tres o más son agentes, independientemente de cómo se llamen internamente.
• Para cada agente, determina la identidad con la que se autentica. Si es compartida o pertenece a un usuario humano, esa es la primera corrección pendiente.
• Localiza las acciones irreversibles y comprueba si un humano las revisa antes de ejecutarse, y si esa persona dispone de tiempo real para examinarlas.
• Comprueba qué memoria se conserva, durante cuánto tiempo y si está aislada por usuario.
• Incorpora esta frontera a tu proceso de gestión de cambios. Añadir una herramienta, retirar una confirmación o habilitar memoria debería activar una revisión, porque cada cambio desplaza el sistema al otro lado de la línea.

La pregunta verdaderamente útil consiste en si una mala decisión produce una respuesta errónea o una acción perjudicial, al margen del nombre comercial del sistema. Todo lo demás se deriva de ahí.

Fuentes

1. OWASP Top 10 for Agentic Applications 2026, OWASP GenAI Security Project, publicado el 9 de diciembre de 2025: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
2. OWASP Top 10 for LLM Applications 2026, OWASP GenAI Security Project, publicado el 3 de agosto de 2026: https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/