Límites para un agente de IA

Por qué un agente necesita límites

Un asistente de chat que responde preguntas puede equivocarse, y eso ya es un problema. Un agente que actúa puede equivocarse y además hacer algo al respecto: reembolsar el pedido equivocado, escribir al cliente equivocado, borrar el archivo equivocado. Los modelos de lenguaje también son fáciles de engañar, ya sea por la persona que los usa o por el texto que leen por el camino.

El Top 10 de OWASP para aplicaciones con LLM nombra los riesgos que más importan aquí, entre ellos la inyección de prompts, la agencia excesiva y el consumo sin límites ^[1]. Cada uno tiene una respuesta práctica, y ninguna depende de que el modelo se comporte a la perfección. Son los mismos controles que pondría a un empleado nuevo con acceso a sistemas reales: acceso limitado, supervisión en las decisiones importantes, un límite de gasto y un registro de lo que ha hecho.

Dele las menos herramientas posibles, con el mínimo acceso

Las herramientas de un agente son las funciones a las que puede llamar: buscar en la base de conocimientos, consultar un pedido, crear un ticket, emitir un reembolso. OWASP describe la agencia excesiva como un sistema con más funciones, más permisos o más autonomía de los que necesita su tarea, y recomienda limitar al mínimo necesario tanto las herramientas que puede llamar un agente como lo que puede hacer cada una ^[2].

• Las herramientas concretas son mejores que las generales. Una herramienta que consulta un pedido por su número es más segura que una que ejecuta cualquier consulta en la base de datos.
• Primero leer, después escribir. Empiece con herramientas de solo lectura y añada la capacidad de cambiar cosas acción por acción, a medida que el agente se gana la confianza.
• Actuar como el usuario, no como administrador. OWASP recomienda ejecutar las herramientas en el contexto del propio usuario y no mediante una cuenta con privilegios, para que el agente nunca pueda hacer más de lo que podría la persona a la que ayuda ^[2].
• Comprobar los permisos en el sistema al que se llama, no solo en el prompt. El sistema de destino debe rechazar una acción que el usuario no tiene permitida, pida lo que pida el modelo ^[2].

Trate como no fiable todo lo que lee

La inyección de prompts es un texto que intenta cambiar lo que hace el modelo. Puede venir directamente del usuario, o indirectamente del contenido que lee el modelo, como una página web, un correo o un archivo ^[3]. A un agente que lee el correo de un cliente y además tiene una herramienta de reembolsos, ese mismo correo le puede ordenar que emita un reembolso.

• Mantenga separadas las instrucciones y los datos, y marque claramente el contenido externo como no fiable, como recomienda OWASP ^[3].
• Defina el formato de salida y compruébelo con código corriente, no con otro modelo, antes de actuar ^[3].
• No permita nunca que el contenido que lee el agente amplíe sus propios permisos. Un documento no puede conceder acceso; solo sus sistemas pueden.
• Haga pruebas con entradas maliciosas antes de la puesta en marcha y con regularidad después, igual que probaría cualquier otro control de seguridad ^[3].

Ponga personas en los puntos de control adecuados

No todas las acciones necesitan a una persona, y pedir aprobación para todo enseña a la gente a pulsar sí sin leer. Clasifique las acciones según lo que costaría un error, y exija aprobación solo donde importa. OWASP recomienda la aprobación humana para las acciones de alto impacto ^[2].

Presupuestos: pasos, tiempo y gasto

Un agente trabaja en bucle: piensa, llama a una herramienta, lee el resultado y vuelve a pensar. Sin límites, un agente confundido puede dar vueltas mucho tiempo, y cada vuelta consume tokens o tiempo de GPU. OWASP considera el consumo sin límites un riesgo en sí mismo, incluidos los atacantes que inflan a propósito una factura de pago por uso, y recomienda límites de frecuencia, cuotas, tiempos máximos y monitorización ^[4].

• Un número máximo de pasos por tarea. Cuando se alcanza, el agente se detiene y pasa a una persona lo que tiene hasta ese momento.
• Un límite de tiempo por tarea y por llamada a una herramienta, para que un sistema lento no lo bloquee todo.
• Un límite de gasto por tarea, por usuario y por día, que su código aplica antes de cada llamada al modelo.
• Límites al tamaño de la entrada, para que nadie pueda pegar una biblioteca entera en el cuadro de chat.
• Alertas cuando el uso se sale de lo normal, enviadas a alguien que pueda actuar.

Los presupuestos también hacen previsible el coste de funcionamiento. Los ejemplos de abajo muestran el coste mensual del modelo con un nivel de uso dado; los límites son lo que lo mantiene ahí.

Evaluación antes y después de la puesta en marcha

No se puede saber si un agente es seguro y útil probándolo unas cuantas veces. Necesita un conjunto de tareas realistas con resultados correctos conocidos, ejecutadas automáticamente, antes de la puesta en marcha y antes de cada cambio. El Marco de Gestión de Riesgos de la IA del NIST, un marco voluntario para incorporar la fiabilidad al diseño, el desarrollo, el uso y la evaluación de los sistemas de IA, es una estructura útil para decidir qué medir y quién responde ^[5].

1. 01

   Reúna tareas reales

   Preguntas y peticiones de las personas que usarán el agente, con el resultado correcto de cada una, incluidas las tareas que debe rechazar o pasar a una persona.

2. 02

   Añada casos maliciosos

   Instrucciones inyectadas en documentos, peticiones de cosas que el usuario no tiene permitidas e intentos de hacerlo entrar en bucle.

3. 03

   Puntúe algo más que la respuesta

   ¿Usó las herramientas correctas, en el orden correcto, dentro del presupuesto, y se detuvo cuando debía?

4. 04

   Fije un listón y manténgalo

   Acuerde la puntuación que debe alcanzar para entrar en producción. Un cambio que baje de ella no se publica.

5. 05

   Siga evaluando en producción

   Tome muestras de conversaciones reales, revíselas y añada los fallos al conjunto de pruebas.

Registros, monitorización y un interruptor de apagado

• Registre cada paso: qué se pidió al agente, a qué herramientas llamó y con qué entradas, qué recibió y qué hizo. Enmascare los datos personales en los registros como haría en cualquier otro sitio.
• Haga que cada acción se pueda atribuir a un usuario y una tarea, para poder explicar un cambio extraño en un registro.
• Vigile las tasas de error, los traspasos a personas, las negativas y el gasto, y revise cada semana una muestra de conversaciones.
• Tenga un interruptor de apagado que no requiera un despliegue: un ajuste que desactive al momento el agente, o una sola herramienta.
• Deje por escrito quién responde del comportamiento del agente y quién decide cuándo apagarlo.

Empiece por poco y amplíe con pruebas

Los agentes más seguros empiezan pequeños. Póngalo en marcha con una tarea bien definida, herramientas de solo lectura y unos pocos usuarios de confianza. Vigile los registros y las puntuaciones de evaluación durante unas semanas. Después amplíe una cosa cada vez: más usuarios, luego una herramienta que escribe, luego menos aprobaciones en las acciones que se han demostrado seguras. Cada paso es una decisión basada en pruebas, y cada uno se puede deshacer.

Es más lento que activarlo todo de golpe, y es así como los agentes acaban siendo de confianza en lugar de apagados tras el primer incidente. También da tiempo a quienes trabajan junto al agente para aprender en qué es bueno y para decirle a usted en qué no lo es.

Dos agentes, con el precio de nuestra tarifa

Los ejemplos prácticos de abajo muestran la horquilla de nuestra tarifa de hoy, con el desarrollo y el coste mensual de funcionamiento. El desarrollo incluye las herramientas, los permisos, los pasos de aprobación, los presupuestos y el conjunto de evaluación; forman parte del agente, no son extras.

Lista de comprobación antes de poner en marcha un agente

1. 01

   Herramientas enumeradas y acotadas

   Cada herramienta nombrada, con lo que puede leer y cambiar, y nada más.

2. 02

   Permisos aplicados en destino

   Los sistemas a los que llama el agente comprueban por sí mismos los derechos del usuario.

3. 03

   Aprobaciones para las acciones de alto impacto

   El dinero, los borrados, los permisos y los mensajes salientes necesitan a una persona.

4. 04

   Presupuestos fijados y aplicados en el código

   Pasos, tiempo, gasto por tarea y por día, y tamaño de la entrada.

5. 05

   Evaluación superada

   Tareas reales y maliciosas, puntuadas, en el listón acordado o por encima.

6. 06

   Registros, alertas e interruptor de apagado probados

   Alguien lo ha apagado y vuelto a encender, a propósito, antes de la puesta en marcha.