Cuándo una IA puede pasar de recomendar una acción a ejecutarla

Una IA puede decir «conviene cancelar esta suscripción» o «envía este correo». Eso es texto: una recomendación que no cambia nada por sí sola. Otra cosa muy distinta es que pueda llamar a una API, modificar un registro o enviar el mensaje de verdad. Confundir las dos —la frase persuasiva y la acción real— es el error de diseño que convierte una respuesta convincente en una autorización implícita, y es la frontera que hay que entender antes de dar a un agente una sola llave. La capacidad que se lleva usted de aquí no es si un agente «puede» actuar, sino qué permiso mínimo necesita, quién confirma cada salto y qué pasa si se equivoca.

Tres escalones, y el riesgo salta en cada uno

Conviene separar tres niveles que el lenguaje comercial tiende a fundir. En la recomendación, el modelo ofrece una opción y no toca nada: el usuario decide. En la propuesta, prepara una acción concreta —un destinatario, un importe, una fecha, un cambio— y la deja lista para revisión, pero sigue sin ejecutarse. En la ejecución, una integración usa un permiso real y modifica un sistema externo: manda el correo, hace el pago, borra el registro. El riesgo no crece de forma gradual entre estos escalones; da un salto en el último, porque solo ahí una interpretación equivocada deja consecuencias en el mundo en vez de en una pantalla.

Ese salto importa especialmente porque un agente decide qué hacer leyendo texto, y el texto se puede manipular. Si un agente con permiso de escritura lee un correo, un documento o una página que contiene instrucciones ocultas, puede acabar ejecutando lo que un tercero quiso y no lo que su dueño pidió. Es la misma familia de riesgo que preocupa en la seguridad de agentes: el poder de actuar, combinado con una entrada no confiable, convierte una herramienta útil en una superficie de ataque. Por eso el permiso mínimo no es burocracia: es el cortafuegos entre un error de lectura y un daño real. Y explica por qué la solución no es «hacer al modelo más listo»: por muy bueno que sea razonando, sigue decidiendo a partir de un texto que otro pudo escribir, de modo que la defensa no está en su cabeza sino en lo que su token le deja tocar. Un agente brillante con permiso de borrado es más peligroso, no menos, que uno mediocre que solo puede leer.

Un ejemplo lo aterriza. Imagine un agente que gestiona notas de gasto. En el primer escalón, señala: «esta factura parece duplicada de la del martes» — una recomendación que un humano puede ignorar. En el segundo, prepara el correo de rechazo al proveedor, con el importe y el motivo, y lo deja en borrador para que alguien lo lea. En el tercero, emite el reembolso o bloquea el pago en el sistema contable. El mismo agente, la misma inteligencia: lo que cambia entre ser inofensivo y ser peligroso no es su capacidad de razonar, sino qué permiso tiene activado y si alguien confirma antes del tercer paso. Diseñar bien es decidir, para cada acción, en qué escalón se queda por defecto.

Qué es un permiso, de verdad

La documentación de OAuth 2.0 lo formaliza: un token concede acceso a recursos y operaciones definidos por unos scopes, no a todo lo que el sistema podría hacer. Un agente no obtiene permiso porque su explicación suene razonable ni porque «entienda» la tarea; solo puede ejecutar exactamente lo que su token autoriza, ni un paso más. De ahí el principio de alcance mínimo: dar el permiso más estrecho que la tarea necesita reduce el daño posible si el agente malinterpreta una instrucción o tropieza con información manipulada. Un token que solo lee no puede borrar aunque el modelo, confundido, «decida» que hay que borrar.

Traducido a diseño, eso significa no usar la misma regla para todo. Un agente puede resumir facturas sin poder pagarlas; puede redactar un borrador de correo sin enviarlo; puede crear una petición de compra que una persona aprueba antes de que se convierta en un pedido. La confirmación humana no es un adorno cuando el coste de un error es alto o difícil de revertir: es el punto donde se para el escalón de ejecución hasta que alguien responsable dice que sí.

Por qué el registro no es opcional en un agente

De las cuatro comprobaciones que vienen ahora, la del registro merece un aparte, porque en un agente que actúa es lo único que permite responder a la pregunta más importante después de un fallo: por qué hizo lo que hizo. Un asistente que solo recomienda deja su rastro en la pantalla; un agente que ejecuta reparte sus efectos por sistemas externos, y sin un registro de qué instrucción recibió, qué datos leyó, qué permiso usó y qué resultado produjo, un error se vuelve imposible de reconstruir y, por tanto, de corregir o de atribuir. La trazabilidad no es un lujo de auditoría: es la condición para poder discutir los fallos de un sistema sin que la responsabilidad se diluya entre «lo decidió la IA» y «yo solo apreté un botón».

Cuatro preguntas antes de automatizar

De todo lo anterior sale una lista corta que sirve para cualquier integración. Alcance: ¿el agente puede leer, proponer, o también escribir y borrar? Confirmación: ¿la acción es reversible, rutinaria y de bajo impacto —y puede ir sola—, o requiere una aprobación humana explícita? Registro: ¿queda constancia de la instrucción recibida, los datos usados, el permiso invocado y el resultado, de modo que se pueda auditar después? Reversión: ¿se puede deshacer, pausar o acotar el efecto si algo sale mal? Un «no» en cualquiera de las cuatro no prohíbe automatizar, pero marca dónde hace falta un freno antes de hacerlo. La reversibilidad manda sobre las demás: una acción que se puede deshacer tolera más autonomía que una irreversible, aunque ambas parezcan igual de rutinarias. Enviar un correo y hacer una transferencia pueden costar lo mismo de teclear; deshacerlos no.

Un marco para no improvisar el freno

Esas preguntas no son una ocurrencia: encajan en un marco reconocido. El AI Risk Management Framework de NIST organiza el trabajo en cuatro funciones —gobernar, mapear, medir y gestionar el riesgo—. Aplicadas a un agente que actúa, se leen así: gobernar es definir quién responde por una acción; mapear es entender en qué contexto se usa y qué puede tocar; medir es saber qué fallos se vigilan y con qué señales; y gestionar es tener cómo detenerlo, corregirlo o revertirlo. El perfil de IA generativa que acompaña al marco no certifica ninguna integración concreta —no existe un sello que diga «este agente es seguro»—; recuerda que el riesgo depende del caso de uso, y que el mismo agente puede ser inofensivo redactando y peligroso ejecutando.

La conclusión práctica es sobria y liberadora a la vez: una IA puede ser muy útil sin recibir las llaves del sistema. La mayor parte del valor de un asistente vive en los dos primeros escalones —recomendar y proponer—, donde el coste de un error es una frase que se descarta, no un pago que se recupera. La pregunta correcta ante cualquier promesa de «agente autónomo» no es «¿puede hacerlo?», sino «¿qué permiso mínimo necesita, quién confirma el salto a ejecución y qué ocurre exactamente si se equivoca?». Quien sabe hacer esas tres preguntas puede aprovechar un agente sin entregarle algo que no debería tener.