¿Qué deberíamos permitir que hiciera un asistente de IA?
Un asistente capaz de enviar mensajes o reservar un viaje necesita límites claros, además de respuestas convincentes.
Pide a un sistema de IA que busque un hotel y quizá te dé una lista de opciones. Conéctalo a herramientas de reserva y tal vez pueda reservar una habitación. La conversación puede parecer similar, pero la segunda acción crea un compromiso.
Un agente de IA es un programa capaz de utilizar herramientas y dar pasos para completar una tarea. Puede leer un resultado, decidir qué hacer después y llamar a otra herramienta. La pregunta importante no es solo si da respuestas sensatas, sino qué puede cambiar cuando una respuesta es incorrecta.
Empieza por el acceso que necesita
Leer, editar, enviar y eliminar son permisos distintos. Acceder a un documento tampoco es lo mismo que acceder a una cuenta entera. Un asistente que comprueba una reunión no necesita automáticamente todos los correos que has recibido.
Los especialistas en seguridad llaman a este enfoque «mínimo privilegio»: dar al software únicamente el acceso necesario para su tarea. OWASP identifica las funciones, los permisos y la autonomía innecesarios como causas de una capacidad de actuación excesiva: poder hacer más de lo que justifica la tarea.
El acceso de solo lectura también importa, porque puede exponer información privada. Limitar el acceso debe abarcar tanto lo que un sistema puede ver como lo que puede modificar.
Una página web no debe convertirse en quien da las órdenes
Imagina que un asistente lee una página de hotel que contiene una instrucción oculta para enviar tu itinerario a otro lugar. La página debe aportar información sobre el hotel. No tiene autoridad para cambiar tu petición.
Este tipo de ataque se llama inyección indirecta de instrucciones: se introducen órdenes en materiales que el asistente encuentra mientras trabaja. Puede ser una página web, un correo o un documento. Si el sistema confunde esas instrucciones con órdenes fiables, puede actuar contra los deseos del usuario.
Indicar al modelo que ignore esos ataques puede ayudar, pero no constituye una defensa completa. La aplicación también debe restringir las herramientas disponibles y comprobar las operaciones propuestas. Si técnicamente no es posible enviar correos, una página engañosa no podrá utilizar esa herramienta para enviar tu itinerario.
Permite revisar la acción concreta
Un punto de revisión útil muestra qué está a punto de suceder: el destinatario, el mensaje y el archivo adjunto; o el hotel, las fechas, el precio y las condiciones de cancelación. Un vago «¿Continúo?» no ofrece información suficiente para revisar una decisión con consecuencias.
El software que hay detrás debe hacer cumplir esa revisión. Un botón de aprobación no sirve si otra vía permite ejecutar la misma operación sin permiso. Preparar un borrador y enviarlo deben ser pasos realmente separados cuando esa distinción importe.
No todas las acciones necesitan la misma supervisión. Los cambios pequeños y reversibles a menudo se pueden automatizar dentro de unos límites acordados. Publicar abiertamente, gastar dinero o borrar registros importantes merece un control mayor. Esta es una recomendación editorial basada en las consecuencias de los errores, no la afirmación de que una misma regla de aprobación sirva para todas las tareas.
Conserva un registro y una forma de detener la actividad
El historial debe dejar claro qué se intentó hacer, qué se completó y cuándo. Los límites de gasto o de volumen de mensajes pueden reducir el daño de un error. Poder revocar rápidamente el acceso ofrece al usuario una forma práctica de impedir nuevas acciones.
La recuperación también importa. ¿Se puede restaurar un archivo editado? ¿Se puede cancelar una reserva? Algunas acciones son mucho más difíciles de deshacer que otras, y las protecciones deberían reflejar esa diferencia.
Por último, comprueba el resultado externo. Que un asistente diga «Reservado» no equivale a recibir una confirmación del servicio. Un sistema útil distingue entre una acción propuesta, una acción intentada y un resultado confirmado.
Antes de conectar una cuenta
Pregunta qué puede leer el asistente, qué puede modificar, qué acciones requieren revisión y cómo puedes retirarle el acceso. Busca respuestas concretas. «Puede redactar una respuesta, pero no enviarla» dice más que una promesa general de seguridad.
El objetivo es que el asistente haga trabajo útil y que sus facultades sean comprensibles. Una demostración impresionante muestra lo que un sistema puede hacer una vez. Un servicio fiable también deja claro qué no está autorizado a hacer después.
Fuentes y lecturas adicionales
- NIST, Lessons Learned from the Consortium: Tool Use in Agent Systems (2025) (https://www.nist.gov/news-events/news/2025/08/lessons-learned-consortium-tool-use-agent-systems)
- OWASP, LLM06:2025 Excessive Agency (https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)
- NIST, Strengthening AI Agent Hijacking Evaluations (2025) (https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations)
- OWASP, LLM Prompt Injection Prevention Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html)