Un chatbot responde. Un agente puede elegir una herramienta, preparar parámetros, desencadenar una acción y observar el resultado. Esta capacidad abre usos útiles: crear un ticket, preparar un pedido, actualizar un expediente u orquestar una búsqueda. También cambia la naturaleza del riesgo. Una respuesta incorrecta se convierte en una operación real.
La seguridad de un agente no depende de su buena voluntad ni de un prompt que le pida ser prudente. Depende de herramientas limitadas, permisos verificados, validaciones, idempotencia y trazabilidad independientes del modelo.
Distinguir conversación, decisión y ejecución
El sistema debe separar:
- la intención expresada por el usuario;
- la interpretación y el plan propuestos por el modelo;
- la decisión de autorizar;
- la ejecución por un servicio determinista;
- la verificación del resultado.
El modelo puede sugerir. La capa de política decide si la herramienta está disponible, si el usuario tiene el derecho y si se necesita una aprobación. El servicio empresarial valida los parámetros y aplica las reglas como en cualquier otra interfaz.
Propagar la identidad del usuario
Un agente no debe actuar bajo una cuenta de administrador genérica. La acción debe estar vinculada a la identidad, a la organización y al contexto de la persona que solicita. Cuando el agente utiliza una cuenta de servicio, lleva una delegación verificable y limitada.
Los derechos se controlan en cada herramienta y recurso. Una conversación anterior no constituye una autorización duradera. Las delegaciones expiran y no pueden ser extendidas por el modelo.
Diseñar herramientas estrechas
Una herramienta segura corresponde a una capacidad empresarial precisa:creer_brouillon_commande, rechercher_dossiers_autorises o proposer_creneaux. Posee un esquema de entrada estricto, validaciones, un perímetro y un resultado estructurado.
Por el contrario, una herramientaexecuter_sql, appeler_url o lancer_commandeda al modelo un espacio demasiado amplio. Incluso protegido por una instrucción, aumenta fuertemente el riesgo de exfiltración o destrucción.
Las herramientas exponen la mínima cantidad de datos y ocultan los secretos. No aceptan parámetros libres cuando es posible una lista permitida.
Clasificar las acciones por nivel de riesgo
Una clasificación pragmática puede distinguir:
- lectura de datos ya autorizados;
- propuesta sin modificación;
- creación reversible en borrador;
- acción con confirmación del usuario;
- acción con aprobación independiente;
- acción prohibida para el agente.
El nivel depende del impacto, del alcance y de la reversibilidad. Enviarse un borrador a uno mismo y enviar un contrato a mil destinatarios no entran en la misma política.
Ciclo seguro de una acción agencial desde la intención hasta la verificación y la compensación.
Previsualizar antes de actuar
Para una acción sensible, el agente produce una representación clara: objeto, destinatarios, datos modificados, cantidad, consecuencias y posibilidad de retorno. El usuario confirma la acción exacta, no una fórmula vaga como «continuar» después de varios intercambios.
La confirmación expira y está vinculada a un hash de los parámetros. Si el agente modifica el pedido, se necesita una nueva validación.
Aplicar la idempotencia
Los agentes pueden repetir una llamada después de un retraso o una respuesta ambigua. Cada operación de creación o pago utiliza una clave de idempotencia y devuelve el estado de un intento existente.
La herramienta distingue entre fallo antes de la ejecución, resultado desconocido y éxito. El modelo no debe adivinar que una operación ha fallado y relanzarla libremente.
Verificar el resultado
Una respuesta HTTP exitosa no garantiza que se haya alcanzado el objetivo comercial. Después de la ejecución, el sistema vuelve a leer el estado, verifica los invariantes y compara el resultado esperado.
El agente solo anuncia lo que está confirmado. Puede decir que una solicitud está «registrada y en espera» en lugar de «procesada» cuando el flujo de trabajo no está terminado.
Prever la compensación
Algunas acciones pueden deshacerse; otras requieren una operación inversa o una intervención. Cada herramienta documenta:
- ventana de cancelación;
- compensación posible;
- datos a conservar;
- responsable;
- comunicación a enviar.
Una transacción financiera o un mensaje externo puede ser difícilmente reversible. El umbral de aprobación debe tenerlo en cuenta.
Defender contra la inyección de prompts
Los correos electrónicos, páginas y documentos consultados pueden contener instrucciones maliciosas. El sistema los trata como datos. No pueden modificar la lista de herramientas, las políticas ni los secretos.
Los datos recuperados están delimitados, las acciones requieren reglas independientes y las salidas se filtran antes de ser utilizadas como parámetros. Una instrucción proveniente de un contenido externo no puede desencadenar una aprobación.
Limitar la exfiltración
Una herramienta de envío o almacenamiento externo puede servir para exfiltrar datos. Los destinos están controlados: dominios, cuentas, canales y volúmenes. Los archivos adjuntos y los campos sensibles son detectados según la política de la organización.
El agente no recibe los secretos de API. Los conectores los utilizan del lado del servidor y nunca los devuelven en los resultados.
Memoria y contexto
La memoria conversacional puede mezclar carpetas, usuarios o períodos. Cada elemento memorizado posee un propietario, un perímetro y una duración. Los datos sensibles no se conservan por defecto.
Antes de una acción, los parámetros críticos se vuelven a leer desde la fuente de la verdad, no desde un resumen de la conversación potencialmente antiguo.
Diario de auditoría
El diario debe permitir reconstruir:
- solicitud e identidad;
- versión de política;
- plan y herramientas seleccionados;
- parámetros validados;
- aprobaciones;
- llamadas y resultados;
- verificación;
- error o compensación.
Los prompts completos no deben conservarse sin necesidad. La journalización respeta la minimización, los derechos de acceso y el tiempo de conservación.
Entornos y límites
Los agentes de prueba no utilizan las herramientas de producción. Las acciones están limitadas por monto, volumen, frecuencia, horario y alcance. Un mecanismo de corte permite desactivar una herramienta o un agente rápidamente.
Las llamadas salientes, descargas y ejecuciones de código pueden colocarse en entornos aislados con red y duración limitadas.
Probar los escenarios adversos
Las pruebas incluyen:
- instrucción maliciosa en un documento;
- usuario sin derecho;
- acumulación de roles;
- parámetro fuera de esquema;
- repetición después de un plazo;
- herramienta no disponible;
- respuesta parcial;
- intento de enviar a un destino prohibido;
- aprobación caducada;
- cambio de parámetros después de la validación.
Los comportamientos esperados se automatizan cuando es posible y se reproducen en cada cambio de modelo o de prompt.
Supervisar la autonomía
Los indicadores siguen la tasa de acciones propuestas, aprobadas, modificadas, fallidas, canceladas y compensadas. Se analizan las diferencias entre el plan y el resultado. Un volumen inusual o un nuevo destino desencadena una alerta.
La autonomía puede aumentarse progresivamente para una herramienta estable, sobre montos y poblaciones limitadas. También puede reducirse de inmediato.
Construir un primer caso de uso
El mejor piloto es frecuente, limitado, reversible y medible. Por ejemplo: buscar información autorizada, preparar un borrador, solicitar una validación y luego crear una tarea. Evita pagos, eliminaciones masivas o decisiones regulatorias.
El piloto establece los fundamentos reutilizables: identidad, motor de políticas, registro de herramientas, aprobación, auditoría y observabilidad.
El agente como nuevo usuario del SI
Un agente debe ser tratado como un actor con un alto nivel de automatización, sometido a más controles, no a menos. Las reglas de negocio permanecen en los servicios, los poderes son limitados y cada acción es demostrable.
Partitech puede diseñar agentes conectados a aplicaciones, API y datos, con herramientas integradas, una gobernanza de permisos y una validación humana. El valor proviene de la automatización segura de un proceso, no del número de herramientas accesibles al modelo.
Hablemos de su proyecto
Identificar y asegurar un primer proceso agéntico con Partitech. Contacte con Partitech.