Agente de IA: qué es, cómo funciona y dónde termina su autonomía

Un agente de IA es un sistema que recibe un objetivo, interpreta el contexto y puede elegir una secuencia de pasos para intentar alcanzarlo. En la formulación de la Agencia Española de Protección de Datos (AEPD), estos sistemas emplean modelos de lenguaje y pueden percibir su entorno, descomponer tareas y realizar operaciones mediante interfaces o herramientas. La palabra agente describe, por tanto, un sistema completo: no es necesariamente el nombre de un modelo concreto.

Un modelo de lenguaje genera o transforma contenido a partir de una entrada. Un agente puede usar ese modelo como parte de un proceso más amplio, junto con instrucciones, datos, memoria, herramientas y reglas de ejecución. La diferencia práctica aparece cuando el sistema no se limita a responder, sino que selecciona acciones y las encadena para cumplir una meta. Un modelo aislado no adquiere por ello permisos para consultar una base de datos o modificar un calendario.

La frontera con un chatbot no es absoluta. Un chatbot puede limitarse a respuestas conversacionales y flujos predefinidos, pero también puede conectarse a herramientas y ejecutar operaciones; en ese momento, algunas de sus funciones se comportan de forma agéntica. Por eso, el canal de conversación no define la categoría. Para entender qué hace un sistema, conviene revisar sus capacidades y permisos, no solo su interfaz o la etiqueta comercial.

La comparación útil distingue tres niveles de funcionamiento. El modelo es el componente que procesa o genera una salida; el chatbot es una aplicación para conversar, que puede usar reglas o modelos; y el agente es un sistema configurado para avanzar hacia un objetivo mediante decisiones y acciones. En productos reales, estos niveles pueden combinarse: un chatbot puede integrar un agente, y un agente puede apoyarse en uno o varios modelos.

La tabla compara funciones posibles, no garantías: que un sistema se denomine agente no demuestra que planifique bien, aprenda de cada interacción o complete tareas sin supervisión. Tampoco todo agente usa un modelo de lenguaje; la guía de la AEPD se ocupa de sistemas agénticos basados en modelos de lenguaje, mientras que el concepto general de agente puede abarcar diseños distintos. En una evaluación técnica, hay que comprobar qué componentes están activos y qué resultados pueden producir.

El funcionamiento suele comenzar con un objetivo expresado por una persona o por otro sistema. El agente recibe información pertinente —por ejemplo, el estado de una solicitud o datos autorizados de una aplicación— y determina qué pasos podrían llevar al resultado. Puede dividir una petición compleja en subtareas, elegir una herramienta para cada una y revisar las respuestas recibidas antes de continuar. La planificación es una secuencia operativa, no una garantía de que el razonamiento sea correcto.

Un ciclo sencillo puede representarse así:

1. Interpretar: convertir la petición en un objetivo y reconocer restricciones relevantes.
2. Planificar: proponer subtareas y decidir qué información falta.
3. Seleccionar: escoger una herramienta disponible y los datos que necesita.
4. Actuar: enviar una consulta o solicitar una operación externa.
5. Evaluar: examinar la respuesta y continuar, corregir el plan o detenerse.

Este ciclo puede repetirse, pero no tiene por qué ocurrir de forma completamente autónoma. La arquitectura determina si el agente puede actuar directamente, si solo propone una acción para aprobación o si debe detenerse ante una condición concreta. En la arquitectura de referencia de Google Cloud para itinerarios, por ejemplo, un agente coordinador reparte tareas entre agentes especializados en lugares, rutas y calendario; el documento también recomienda revisión humana para operaciones críticas. Es un ejemplo de diseño, no una propiedad universal de los agentes.

En sistemas con varios agentes, la coordinación añade otra capa: un componente asigna tareas y reúne resultados, mientras agentes especializados consultan herramientas distintas. La AEPD describe arquitecturas con uno o varios agentes y servicios de apoyo, como almacenamiento, gestión de credenciales y trazabilidad. Más componentes implican más dependencias que gobernar: cada traspaso puede afectar a la calidad del resultado, los permisos y el registro de lo ocurrido.

Las herramientas conectan al agente con funciones que el modelo no realiza por sí solo: consultar una API, recuperar información de una base de datos, comprobar una ruta o proponer cambios en un calendario. El modelo puede decidir cuál solicitar y con qué parámetros, pero el acceso efectivo depende de la integración y de los permisos asignados. Una herramienta convierte una sugerencia en una operación posible; también abre una vía para consultar o modificar datos fuera de la conversación.

La arquitectura publicada por Google Cloud ilustra esta diferencia mediante un planificador de viajes con agentes especializados: el sistema puede obtener información geográfica y de horarios y, con acceso al calendario, gestionar eventos. El mismo diseño contempla componentes de observabilidad para registrar eventos y revisar acciones. La utilidad del ejemplo está en mostrar que el comportamiento depende de interfaces, datos y controles concretos, no de una capacidad mágica del modelo.

Para quien implanta un agente, el criterio central es conceder únicamente el acceso necesario. Si la tarea es redactar un borrador, quizá baste con lectura de documentos; si debe enviar mensajes o modificar registros, esas acciones necesitan permisos y salvaguardas explícitos. Es conveniente separar consultar, proponer y ejecutar, y exigir aprobación antes de acciones con consecuencias relevantes, como una reserva no reversible o una comunicación a terceros.

La autonomía de un agente es acotada por su diseño: instrucciones, herramientas disponibles, datos accesibles, permisos y condiciones de parada. El sistema puede elegir entre opciones permitidas, pero no debe tratarse como una autoridad independiente ni suponerse que entiende todas las consecuencias de una operación. Un agente que puede consultar información no necesariamente puede modificarla; uno autorizado a ejecutar una acción puede hacerlo de manera equivocada si interpreta mal el objetivo o recibe datos inexactos.

La AEPD advierte que la interacción con servicios internos y externos puede cambiar el alcance de un tratamiento de datos personales. Entre los riesgos que aborda están la exposición de información al interactuar con el entorno, la dependencia de servicios integrados, la conservación inadecuada en memoria y las decisiones basadas en datos imprecisos o no pertinentes. La supervisión humana efectiva es especialmente importante cuando las acciones pueden afectar de forma significativa a personas o derechos.

La trazabilidad debe permitir reconstruir qué solicitud recibió el sistema, qué datos y herramientas intervienen, qué acciones intentó y quién aprobó las operaciones que lo requerían. Registrar solo la respuesta final puede no bastar para investigar un error. La AEPD recomienda abordar el sistema durante todo el ciclo de vida del tratamiento, con gobernanza, evaluación de riesgos y controles adecuados; la arquitectura de Google Cloud también presenta registros y revisión de eventos como elementos de observabilidad.

La intervención humana no equivale a que alguien pueda mirar una pantalla sin capacidad real de influir. Un control útil define qué decisiones requieren aprobación, quién puede pausar o anular una operación y cómo se gestionan errores o solicitudes de derechos. En tareas rutinarias y reversibles puede bastar una revisión posterior; en operaciones sensibles o difíciles de revertir, la aprobación previa ofrece una barrera más clara.

La guía de la AEPD, publicada en febrero de 2026, aborda la IA agéntica desde la perspectiva de la protección de datos personales. Su propósito es ayudar a responsables y encargados a evaluar cómo cambia un tratamiento cuando se incorpora un agente. La Agencia señala que el agente puede realizar una parte o la totalidad de un proceso y que su integración puede alterar finalidades, flujos de información, intervinientes y riesgos. Añadir un agente puede cambiar el tratamiento, aunque la organización ya utilizara los datos antes.

En la práctica, una evaluación debe identificar qué datos consulta el sistema, qué proveedores o servicios participan, dónde se almacena la memoria y los registros, y qué operaciones puede ejecutar. También debe comprobarse si la nueva configuración respeta la finalidad y la minimización: dar acceso a más repositorios de los necesarios aumenta el alcance potencial del tratamiento. La guía recomienda revisar las obligaciones y los riesgos al incorporar el sistema, en lugar de asumir que la evaluación anterior sigue cubriendo el nuevo flujo.

La guía de la AEPD se centra en la protección de datos personales cuando se incorpora IA agéntica a un tratamiento. Para determinar qué obligaciones pueden aplicarse conforme al Reglamento europeo de IA, hay que atender a sus definiciones y requisitos, así como al sistema y al uso concreto. El término comercial agente no basta por sí solo: también importan la función, el contexto de despliegue y las responsabilidades de los actores involucrados.

Para una organización que maneja datos personales, una revisión inicial puede plantear estas preguntas:

• ¿Qué objetivo concreto debe cumplir el agente y qué datos necesita para ello?
• ¿Qué herramientas puede consultar o modificar, y con qué permisos?
• ¿Qué operaciones requieren validación humana y cómo se detienen?
• ¿Qué registros permiten revisar las decisiones y atender derechos de las personas?
• ¿Qué proveedores intervienen y cómo se documentan los flujos de datos?

La respuesta práctica no es evitar toda automatización, sino ajustar autonomía y permisos al riesgo. Si una tarea repetitiva puede resolverse con reglas simples, un agente con acceso amplio puede añadir complejidad innecesaria. Si el proceso exige combinar información y coordinar acciones, el diseño debe incluir límites, supervisión y trazabilidad desde el principio.