Elegir seguridad para agentes de IA empieza por una acción empresarial que necesita protección y por exigir una demostración en vuestro entorno. Un nombre comercial, una lista de funciones o un ejemplo escogido por el proveedor no establecen qué sucederá cuando el agente lea un documento problemático, reciba permisos excesivos o ejecute una acción no deseada.
Estas preguntas sirven para reuniones con proveedores y un piloto limitado. Se apoyan en principios de OWASP sobre permisos, aprobación, pruebas y registros, junto al marco de riesgos de NIST. Son recursos para evaluar riesgos, no una certificación de seguridad del producto. Buscan respuestas comprobables y documentadas para comparar proveedores sobre la misma tarea.
1. ¿Qué cubre exactamente la protección?
¿La herramienta prueba el modelo antes del despliegue, observa un agente activo, aplica permisos o combina funciones? ¿Qué modelos, marcos de desarrollo, servidores MCP, navegadores y nubes admite realmente? ¿Puede entregar un mapa de vuestra arquitectura con rutas que eluden el producto y exclusiones explícitas?
¿Inspecciona solo el texto del usuario y del modelo o también llamadas a herramientas, memoria, credenciales y acciones externas? ¿Quién responde por conexiones incompatibles? ¿Cada capacidad está disponible, en fase preliminar o simplemente prevista, y acepta el proveedor reflejarlo por escrito junto a cada componente?
¿Qué acción empresarial puede recorrer el piloto desde la autorización del usuario hasta el cambio en el sistema de destino, mostrando también dónde no actúa la protección?
2. ¿Se puede reconstruir lo que hizo el agente?
¿Muestra quién pidió la tarea, qué agente la ejecutó, a qué herramienta llamó, con qué parámetros y qué cambió? ¿Relaciona agentes delegados con la petición original? ¿Distingue ejecución observada, explicación generada por el agente e interpretación del sistema de vigilancia?
¿Se puede exportar una secuencia completa, incluidos fallos y bloqueos, y leerla sin otra licencia? ¿Cómo aparecen las lagunas y quién recibe aviso si dejan de llegar eventos? ¿Puede un responsable del negocio entender el archivo o necesita al proveedor para interpretar cada suceso?
3. ¿Cómo se prueba antes del lanzamiento?
¿Las pruebas utilizan vuestras herramientas, permisos y límites de datos o solo instrucciones genéricas? ¿Incluyen inyección indirecta mediante documentos externos, filtración de información y acciones prohibidas? ¿Examinan memoria, delegación y elusión de aprobaciones sin emplear datos sensibles reales en la demostración?
¿Cada hallazgo incluye un escenario reproducible, versión, resultado esperado y resultado observado? ¿Quién repite las pruebas tras una corrección o sustitución del modelo? ¿Se ejecutan tareas normales junto a las pruebas adversarias para detectar bloqueos excesivos, y se conserva una lista acordada de problemas pendientes?
4. ¿Qué sucede durante un incidente real?
¿El producto solo alerta o puede bloquear una llamada, revocar credenciales, aislar la ejecución o detener el proceso? ¿Cuánto tarda cada respuesta en vuestro piloto? ¿Quién recibe el aviso, por qué canal y quién autoriza volver a operar?
¿Qué ocurre con tareas en cola y acciones aprobadas? ¿La ejecución continúa o se detiene si el servicio de seguridad falla? ¿Puede organizarse un ejercicio que cubra detección, interrupción, revocación, conservación de evidencias y recuperación, en vez de aceptar una simple alerta en un panel?
5. ¿Cómo se limitan permisos y daños posibles?
¿Se separan lectura y escritura y se restringe por usuario, recurso, destino y tiempo? ¿Aplica la frontera el sistema que ejecuta la acción o solo una instrucción para el modelo? ¿Puede un agente delegado obtener más autoridad que su origen, y qué evita usar el permiso de una persona en la tarea de otra?
¿Se pueden limitar gasto, registros modificados, reintentos y cadenas de herramientas? ¿Qué cubre y excluye el entorno aislado? ¿Puede demostrarse el rechazo de una acción fuera de alcance aunque el agente la presente con seguridad como necesaria para terminar?
6. ¿Cuándo interviene una persona y qué aprueba?
¿Qué acciones requieren aprobación, quién puede concederla y puede vuestra organización modificar ese límite? ¿Ve la persona destino, importe, parámetros y cambio exactos, o solo un resumen redactado por el agente? ¿La aprobación queda vinculada a esa acción e identidad y debe repetirse si algo cambia?
¿Puede reutilizarse una autorización caducada, copiada o consumida? ¿Puede el agente aprobarse a sí mismo o aprovecharse una aprobación en ejecuciones paralelas? ¿Qué pasa si falla la validación? ¿Demostrará el proveedor el rechazo de permisos alterados o reproducidos y dejará constancia de ello?
7. ¿Qué evidencias quedan después del fallo?
¿Se registran hora, usuario, agente, versión de política, decisión, aprobación y resultado? ¿Puede un agente u operador corriente alterar el registro sin detección? ¿Dónde se almacena, quién accede y durante cuánto tiempo? ¿Pueden ajustarse conservación y borrado sin comprometer una investigación abierta?
¿Qué secretos y datos personales se ocultan, y se pierde contexto necesario para investigar? ¿Se integran los registros con el sistema de gestión de eventos de seguridad existente, SIEM, y se exportan en un formato útil? ¿Puede el piloto producir un expediente comprensible por otro compañero sin reconstruir toda la conversación?
8. ¿Cuánto trabajo exige la integración?
¿Qué cambios de código, componentes, intermediarios o permisos administrativos hacen falta? ¿Se integra con identidad, autorizaciones y seguridad existentes o exige reemplazarlas? ¿Quién instala, mantiene y responde si una actualización de modelo, marco o servidor MCP rompe la conexión después del piloto?
¿Qué retraso añade a una tarea real y qué ocurre si un componente no está disponible? ¿Se pueden medir duración, fallos y trabajo manual en el mismo entorno? ¿La oferta incluye implantación, adaptación y compatibilidad o son proyectos que hay que presupuestar aparte?
9. ¿Cuál es el coste total y cómo se abandona el servicio?
¿Se factura por usuarios, agentes, eventos, pruebas, llamadas al modelo o volumen de datos? ¿Qué cargos adicionales existen por almacenamiento, conservación, soporte y revisión humana? ¿Puede presupuestarse vuestra carga prevista con supuestos explícitos y un escenario de alta demanda, en vez de un precio inicial aislado?
¿Cuánto tiempo interno consumirán ajustes, alertas y mantenimiento de reglas? ¿Hay límites de presupuesto y avisos anticipados? ¿Al finalizar se pueden exportar reglas y registros, revocar accesos y borrar datos del proveedor? ¿Quién lo hace, cuánto cuesta y cómo se confirma la finalización?
10. ¿Cómo se convierte el piloto en una decisión de compra?
¿Se evalúan todos los proveedores con la misma tarea, datos sintéticos y límites? ¿Negocio, ingeniería y seguridad han acordado qué debe bloquearse, qué debe seguir funcionando y qué pruebas se necesitan? ¿Incluyen las pruebas los idiomas de trabajo reales, como hebreo, árabe, español, hindi o inglés cuando corresponda?
¿Se registran por separado capacidades demostradas, no probadas y promesas futuras? ¿Quién acepta el riesgo residual y cuándo se repetirá la evaluación tras cambios importantes? ¿Puede la decisión explicar qué añade la herramienta a los controles de acceso y la respuesta a incidentes sin afirmar que superar el piloto garantiza protección universal?