Tu agente no es un becario. Es un usuario con permisos.

«Es como tener un becario digital». Un becario al que has dado acceso al correo, a la carpeta de clientes y al botón de enviar. Igual la analogía necesita una segunda vuelta.

Casi todo lo que vas a leer sobre agentes de IA empieza por lo mismo: qué son, qué prometen, cuánto ahorran. Falta la parte incómoda. Un agente no es una respuesta: es una cuenta con permisos que ejecuta cosas mientras tú miras otra pantalla. De eso no habla el folleto.

Qué es un agente de IA, en serio

La definición de vendedor dice que un agente de IA es un sistema capaz de planificar y actuar de forma autónoma para cumplir un objetivo. Correcta, y bastante inútil para decidir una compra. El término tampoco es nuevo: los agentes de inteligencia artificial aparecían en los manuales mucho antes de que existiera un chat al que preguntarle cosas. Lo nuevo es lo que ahora llevan enchufado.

La formulación que a mí me sirve es otra. Un agente de IA es un modelo de lenguaje con herramientas conectadas y un permiso para usarlas sin preguntar cada vez. Ahí están las tres piezas que importan: el modelo, que puede equivocarse; las herramientas, que tocan sistemas reales como el correo, los ficheros, el calendario o la base de datos de clientes; y el margen de autonomía, que decide cuántas de esas acciones ocurren sin que nadie las mire antes.

Cambia el tercer elemento y cambia el riesgo entero, aunque el modelo sea exactamente el mismo. Por eso dos productos con el mismo motor pueden merecer decisiones opuestas.

Un chatbot te contesta. Un agente actúa en tu nombre

La diferencia no es la inteligencia. Es el alcance del daño cuando falla.

Un chatbot que se inventa una cifra produce un párrafo equivocado que tú lees y tiras. Un agente que se inventa esa misma cifra puede mandarla a un cliente, adjuntarla a un expediente y crear una tarea de seguimiento para el lunes. El error tiene idéntica causa; la consecuencia sale de tu edificio. Por eso me interesa poco la conversación sobre si el modelo es más listo que el del mes pasado. Me interesa qué puede tocar.

Al analizar una herramienta de despacho empezaría por sus capacidades, no por la simpatía del chat. Leer un documento es un poder. Modificarlo, otro. Enviar una conclusión fuera del despacho, otro muy distinto. No los metería en el mismo saco porque la demo tenga una única ventana.

Los agentes de IA no fallan por tontos: fallan por permisos

OWASP describe la agencia excesiva como un riesgo relacionado con conceder demasiadas funciones, permisos o autonomía a un sistema basado en modelos de lenguaje. Una respuesta manipulada o equivocada puede entonces convertirse en una acción dañina. El problema no se limita al texto que produce el modelo. Fuente primaria ↗

Hay un segundo hilo que casi nadie enlaza con el primero. En otra entrada de la misma guía, OWASP distingue la manipulación directa mediante entradas del usuario y la indirecta mediante contenido externo que el modelo procesa. Ambas pueden alterar el comportamiento previsto, y el riesgo puede existir aunque la instrucción no resulte evidente para quien mira el documento. Fuente primaria ↗

Junta las dos piezas y tienes el problema completo. Un fichero cualquiera puede intentar dar órdenes, y lo que ocurra después depende exclusivamente de qué le dejaste hacer al agente. La misma frase manipuladora es una anécdota si el agente solo lee, y un incidente si el agente puede enviar. La barrera decisiva no está en el texto. Está en el permiso.

El recorrido que pediría ver en una demostración

Usaría datos sintéticos. Daría al sistema acceso de lectura a un expediente de prueba y le pediría un borrador. Después comprobaría dentro de ese entorno, con autorización previa, que no puede leer otro expediente, enviar el resultado a un destinatario no aprobado ni ampliar sus propios permisos.

No es una prueba de intrusión contra terceros. Es una especificación de aceptación de mi propio proceso. La diferencia importa: que algo sea técnicamente accesible no lo convierte en autorizado.

Añadiría un caso sintético más, el que suele descolocar una demostración: incluir en el expediente de prueba un documento que contenga instrucciones dirigidas al agente. No para presumir de que el modelo «se da cuenta», sino para ver qué barrera externa queda en pie el día que no se dé cuenta. Si la única respuesta es que el prompt del sistema está muy bien escrito, me quedo con la pregunta que traía.

La aprobación debe ocurrir antes de la acción

Me serviría una pantalla que muestre la operación exacta: qué documento sale y en qué versión. A quién va y con qué adjuntos. No me serviría una aprobación genérica al principio de una sesión que luego autorice todas las decisiones que el agente tome por el camino.

También pediría que la autorización caducase, que un cambio material la invalidase y que la política de permisos no dependiese de que el modelo obedeciera un recordatorio. Son criterios de diseño que habría que probar, no propiedades que se consiguen escribiendo «sé prudente» en una instrucción.

Mi separación mínima son cuatro verbos que casi nunca vienen separados de fábrica: leer, proponer, aprobar y ejecutar. Los dos primeros puede hacerlos el agente. El tercero es de una persona con nombre y con capacidad real de decir que no. El cuarto solo debería ocurrir después del tercero, y sobre la versión exacta que se aprobó. Cuando esos cuatro verbos viven dentro del mismo botón, no tienes un flujo de trabajo: tienes un pasillo sin puertas.

Agentes de IA en empresas: por dónde empezaría

NIST anunció en febrero de 2026 una iniciativa de estándares para agentes centrada en confianza, seguridad e interoperabilidad. Es una señal institucional de atención al problema, no un sello que certifique tu producto. Fuente primaria ↗

Mientras esa conversación madura, el mismo organismo mantiene un perfil de riesgos para IA generativa, presentado para uso voluntario, que sirve para estructurar preguntas y controles. No certifica a nadie, tampoco a quien lo cita en un artículo. Fuente primaria ↗

Traducido a una oficina con clientes reales, mi punto de partida sería lectura delimitada y propuestas reversibles, con cualquier salida externa bajo control. Ampliaría la autonomía solo cuando pudiera justificar el beneficio y comprobar los controles con tareas representativas. Empezaría por las tareas donde un error se ve pronto y se corrige barato, no por la operación más vistosa para enseñar en una reunión.

Y dejaría una pregunta encima de la mesa antes de firmar nada: si mañana este agente hace algo que no debía, ¿qué registro me permite reconstruir qué versión salió y con qué permiso? Si la respuesta llega envuelta en adjetivos, ya tengo la información que buscaba.

Un agente no debería heredar todo tu poder por el simple hecho de ayudarte. Delegar una tarea no obliga a delegar todas las llaves.

Lo que me preguntan cuando cierro el portátil.

¿Qué es un agente de IA?

Un agente de IA es un modelo de lenguaje con herramientas conectadas y permiso para usarlas sin consultar cada paso. La diferencia con otros usos de la IA no está en lo que sabe, sino en lo que puede ejecutar: leer ficheros, modificar documentos, enviar correos o lanzar operaciones dentro de sistemas reales de la empresa.

¿Qué diferencia hay entre un chatbot y un agente?

El chatbot devuelve texto y ahí acaba su alcance: tú decides qué hacer con esa respuesta. El agente ejecuta acciones con las herramientas que le has conectado. Cuando ambos se equivocan, el fallo es idéntico, pero el del chatbot se queda en tu pantalla y el del agente puede salir hacia un tercero.

¿Qué permisos debería tener un agente de IA en una empresa?

Los mínimos para su tarea, y separados por verbo: leer, proponer, aprobar y ejecutar no deberían compartir un solo botón. Conviene delimitar a qué expedientes accede, impedir que amplíe sus propios permisos, limitar los destinatarios de cualquier salida externa y exigir una autorización previa vinculada a la versión y la operación exactas.

El expediente detrás del artículo.

LLM06:2025 · Agencia excesiva ↗OWASP GenAI Security Project · 2025
Guía técnica de riesgosLLM01:2025 · Prompt injection ↗OWASP GenAI Security Project · 2025
Guía técnica de riesgosIniciativa de estándares para agentes ↗NIST · anuncio del 17 de febrero · 2026
Iniciativa institucional; no certificaciónPerfil de riesgos de IA generativa ↗NIST · AI 600-1 · 2024
Marco técnico voluntario

Fuentes consultadas el 9 de septiembre de 2026. Las recomendaciones y ejemplos son elaboración editorial: no se atribuyen íntegramente a estas fuentes. Comprueba versión y ámbito antes de aplicar una norma.

Divulgación general. Ninguna herramienta de esta web certifica la revisión, seguridad o conformidad de un proceso.