Un agente de IA solo debe hacer acciones autorizadas de forma explícita dentro de un proceso definido. Responder a una pregunta, preparar una propuesta y comprometer a la empresa con una promesa implican responsabilidades distintas. Los sistemas conectados tienen que hacer cumplir esos límites, y unos resultados observables tienen que confirmar que funcionan.
Un asistente puede parecer muy seguro e ignorar un hecho esencial. Una formulación segura no puede sustituir una aprobación comercial. Las preguntas útiles son concretas: ¿qué puede leer el sistema, qué puede modificar y quién es responsable de ese cambio?
Empezar por la acción
En un escenario hipotético de showroom, el mismo asistente podría explicar el horario de apertura, preparar una solicitud de visita y proponer una cita disponible. Cada acción tiene consecuencias distintas.
Leer el horario público no pide acceso a todas las fichas de clientes. Proponer una franja no la reserva. Confirmar una visita pide una operación correcta en el sistema de reservas, en las condiciones que ha aceptado el usuario.
Definiríamos los permisos para cada paso. Si el proceso no necesita una función, el sistema no debe tener acceso a ella solo porque una integración la ofrezca.
| Acción posible | Condición de diseño |
|---|---|
| Explicar información pública | Usar una fuente validada y actualizada |
| Preparar un resumen | Separar los hechos indicados de las incógnitas |
| Registrar una solicitud | Recoger la información necesaria, comprobar el acceso y evitar duplicados |
| Confirmar una cita | El usuario la ha elegido y el sistema de reservas la ha confirmado |
| Proponer un descuento excepcional | Obtener la aprobación del rol comercial designado |
| Modificar un contrato | Seguir un proceso aparte de autorización y revisión |
Es un reparto posible de responsabilidades. Los límites finales dependen del servicio, de las consecuencias de un error y del funcionamiento de la empresa.
La autorización tiene que existir más allá de la conversación
Una instrucción de evitar descuentos es útil, pero el sistema conectado también tiene que restringir las operaciones disponibles. Si una herramienta puede aplicar cualquier descuento sin una comprobación independiente, la conversación se convierte en el único filtro de una decisión comercial.
OWASP trata la autonomía excesiva (en inglés) desde el punto de vista de las funciones, los permisos y la autonomía de que dispone un sistema. Responderíamos a este riesgo con un acceso limitado a las operaciones necesarias y comprobaciones proporcionales a sus consecuencias.
La identidad también cuenta. Una pregunta sobre un producto puede recibir una respuesta pública. Una solicitud sobre un pedido tiene que vincularse a un cliente verificado antes de mostrar detalles privados. Conocer un número de pedido no debe considerarse automáticamente una prueba suficiente.
¿Y las instrucciones que contienen los documentos?
Un documento enviado para un presupuesto puede contener requisitos técnicos junto a un texto que pide al sistema ignorar sus reglas o revelar otra información. El contenido recibido es material que hay que analizar. No adquiere autoridad para cambiar los permisos del proceso.
Es un tipo de problema que cubren las recomendaciones de OWASP sobre la inyección de prompts (en inglés). En nuestro ejemplo, un documento puede alimentar el resumen, mientras que la aprobación de las acciones depende de un mecanismo de autorización aparte.
La persona que aprueba necesita información suficiente para decidir
Una aprobación es útil cuando la persona puede ver qué va a pasar: el destinatario, la información usada, el compromiso propuesto y las preguntas sin resolver. Un botón de aprobación junto a un resumen incompleto puede trasladar la responsabilidad sin mejorar la decisión.
También mostraríamos las fuentes relevantes, los cambios respecto a la solicitud original y el siguiente paso. Para las operaciones sensibles, estableceríamos quién puede aprobarlas, cómo se registra la decisión y cómo puede detenerse el proceso.
¿Cómo probar los límites?
Incluye solicitudes que el sistema tiene que rechazar o traspasar: el pedido de otro cliente, un descuento no autorizado, información contradictoria, una integración no disponible o un envío repetido. Comprueba el estado del sistema que resulta, no solo la respuesta que se muestra.
En NOT MORE., podemos definir estas responsabilidades con tu equipo, y después diseñar e implementar el proceso acordado. Más autonomía es útil cuando el proceso, los permisos y la valoración lo permiten.
¿Qué acción dejarías que el sistema hiciera solo, y qué querrías ver antes de aprobarla?